Device Drivers' Interface
Device Drivers' Interface
I have moved to Sussex and I haven't had time to work on my kernel for almost a week. I finally got back to writing my ATA driver and I started thinking of writing each of the device drivers independent of th kernel somehow so that for example, mice drivers can be stored on files and the kernel will be able to load them dynamically so they don't necessarily have to be hard-coded into the kernel. Then I started searching around the forum to find similar posts but I didn't have much luck. So, I'd really appreciate it if you guys could give me a lowdown on how such thing should be implemented (the drivers and the interface). For example, I need to write an ATA driver to load files from the disk but that will be hard-coding the driver into the kernel and so on...
On the field with sword and shield amidst the din of dying of men's wails. War is waged and the battle will rage until only the righteous prevails.
You're confusing me.
As such I don't understand what concept you need describing... :S
ATA has no concept of a 'file'. It has the concept of sectors, and at the highest level the concept of a partition table. It is a concretion of a block device. Your filesystem driver is responsible for making sense of this byte-stream and 'loading files'.For example, I need to write an ATA driver to load files from the disk
As such I don't understand what concept you need describing... :S
I don't think I delivered the problem correctly:
Suppose you are looking at the kernel as a separate component and at device drivers as separate as the kernel. So here it is the kernel in your left hand and device drivers are placed in your right hand. How will you write an interface to allow the device drivers in your right hand to be able to communicate with the left hand's contents that is the kernel? How should the kernel understand what services are supposed to be done by a particular device driver. How should the kernel, for example, "expect" a device driver to do a certain thing or vice versa?
Suppose you are looking at the kernel as a separate component and at device drivers as separate as the kernel. So here it is the kernel in your left hand and device drivers are placed in your right hand. How will you write an interface to allow the device drivers in your right hand to be able to communicate with the left hand's contents that is the kernel? How should the kernel understand what services are supposed to be done by a particular device driver. How should the kernel, for example, "expect" a device driver to do a certain thing or vice versa?
On the field with sword and shield amidst the din of dying of men's wails. War is waged and the battle will rage until only the righteous prevails.
hmm
Couldn't you just use interrupts? Like in DOS a mouse driver always uses int 33h. That's what I'm going to do. Have a standard set of interrupts used for drivers that do certain things, no matter who wrote the driver.
Kernel calls init function of driver. Drivers of different devices supposed to provide fixed set of functions specified by kernel, either driver header has pointers to such functions(I did this way) or driver calls function that tells kernel addresses to such functions.
Before calling init functions of the driver kernel sets up small data area which has basic device info(registers for instance). Pointer to this data is passed to the driver init function.
Driver provides interrupt handler. The handler doesn't have any pop/push - kernel does that before calling interrupt handler.
Option: Kernel can patch handler's 'ret' instruction and replace it with 'iret' and patch beginning (push/pop) - a simple way to put handlers address directly into IDT. I dont know about permissions here - haven't done that yet. (Can't do this if interrupt # that drivers uses is shared)
Now all depends on driver: Int handler can put next job into the kernel list that gets parsed during main OS loop by the kernel. Kernel executes functions from that list. Switch to driver space is done. Or device handler can do all the job. Or driver can maintain its own job list - kernel switches periodically to that driver task.
Example: user does syscall to read sector, kernel puts the request in its job list depending on priority, kernel calls ata 'read sector" function, 'read sector' sends request to the ata drive, upon read completion driver int handler excutes, handler reads status, puts info in the job list that operation is complete and that kernel can notify user program about completion.
Before calling init functions of the driver kernel sets up small data area which has basic device info(registers for instance). Pointer to this data is passed to the driver init function.
Driver provides interrupt handler. The handler doesn't have any pop/push - kernel does that before calling interrupt handler.
Option: Kernel can patch handler's 'ret' instruction and replace it with 'iret' and patch beginning (push/pop) - a simple way to put handlers address directly into IDT. I dont know about permissions here - haven't done that yet. (Can't do this if interrupt # that drivers uses is shared)
Now all depends on driver: Int handler can put next job into the kernel list that gets parsed during main OS loop by the kernel. Kernel executes functions from that list. Switch to driver space is done. Or device handler can do all the job. Or driver can maintain its own job list - kernel switches periodically to that driver task.
Example: user does syscall to read sector, kernel puts the request in its job list depending on priority, kernel calls ata 'read sector" function, 'read sector' sends request to the ata drive, upon read completion driver int handler excutes, handler reads status, puts info in the job list that operation is complete and that kernel can notify user program about completion.
For devices that kernel knows about - driver fulfills 'kernel contract'. Driver provides required functions. If it doesn't user will not be able to use some features/function.
For devices that kernel doesn't know about driver provides single function thru which user program sends request to the device/driver.
For devices that kernel doesn't know about driver provides single function thru which user program sends request to the device/driver.
Thank you exkor; from what I see, it is more OS specific how the driver interacts with the kernel than it is something like a standard way of doing such thing. So for example, the kernel will "expect" a series of addresses and such information to be provided by the device driver and perhaps a signature from the device driver to estate that it actually is a device driver. Now when the kernel receives this information, it should be notified whether or not the device driver actually handles an interrupt or not and such information. I am going to put all this information down on paper and see what the outcome will be. I will post back here soon. Thanks again.
On the field with sword and shield amidst the din of dying of men's wails. War is waged and the battle will rage until only the righteous prevails.