Hi...
I was thinking of a kernel which would try to reduce the amount of work that a device driver does. We generally have a lot of abstractions in kernels which make it possible to write device drivers without doing much work.. You just have to learn to interface it properly with the kernel for the proper class of your driver.
In addition to this I had an idea of letting the kernel perform the common mechanical tasks that a device driver would perform, by the kernel. As an example, the keyboard driver needs to poll the status port for a ready bit (either to read or to write). This could be scheduled asynchronously within the kernel by telling the kernel about the port and the bit that is to be checked.
This would help in improving the kernel performance. Since all the polling activities are performed by the kernel (like for keyboard, serial port, hdd etc..) , there could be some sort of scheduling policy implemented for them. I guess this would reduce the overhead of polling in case of device drivers, since now the polling has been taken over by an intelligent entity - the kernel.
Plus, the kernel could do some kind of profiling in which if one of the device polling succeeds may be after a longer interval (say 20ms) then, it would not waste that much time in polling since it knows that it won't get the result in less than 20ms. This would naturally improve the performance.
By polling i mean to mention the small scale polling that takes place even in presence of interrupts, like that of keyboard. I don't know how big an overhead it is. But i guess for all sorts of devices this kind of polling exists.
Please comment on this...
Offcoding device drivers
-
salil_bhagurkar
- Member
- Posts: 261
- Joined: Mon Feb 19, 2007 10:40 am
- Location: India
Re: Offcoding device drivers
I have implemented exactly such a thing already in my OS. It is part of the "blocking" function -- when a process gives up the rest of its timeslice to wait for some event. So, it is part of my scheduler.
Assume a driver, in the process of handling its hardware, decides that the next thing it needs to do is "poll" for some bit, on some IO port to clear.
The driver uses a system call to tell the scheduler:
I need to block. I am waiting for a byte (or even a bit), on IO port X, to change to value Y, and I want to wait for B clock ticks (which could be infinity) for it to happen.
It is also possible for drivers, kernel processes, and even user processes to block on particular physical memory addresses (this is my main method for handling semaphores).
I have a very high task switching rate, so the blocking list is checked fairly often by the scheduler. It checks the entire list of memory address blocks as a batch, and checks IO ports slightly less often. The task switching mostly depends on the fact that very few processes ever use their entire timeslice, and most are almost always blocked -- waiting for some sort of event or other. All blocked processes are removed from the run queue, until the scheduler unblocks them -- either because the wait was successful, or the timeout expired.
But, as you say, this eliminates the need for drivers (or any program) to have tight polling loops. The OS handles polling for them, at an approprate slower polling rate, that does not interfere with the rest of the operation of the machine.
Assume a driver, in the process of handling its hardware, decides that the next thing it needs to do is "poll" for some bit, on some IO port to clear.
The driver uses a system call to tell the scheduler:
I need to block. I am waiting for a byte (or even a bit), on IO port X, to change to value Y, and I want to wait for B clock ticks (which could be infinity) for it to happen.
It is also possible for drivers, kernel processes, and even user processes to block on particular physical memory addresses (this is my main method for handling semaphores).
I have a very high task switching rate, so the blocking list is checked fairly often by the scheduler. It checks the entire list of memory address blocks as a batch, and checks IO ports slightly less often. The task switching mostly depends on the fact that very few processes ever use their entire timeslice, and most are almost always blocked -- waiting for some sort of event or other. All blocked processes are removed from the run queue, until the scheduler unblocks them -- either because the wait was successful, or the timeout expired.
But, as you say, this eliminates the need for drivers (or any program) to have tight polling loops. The OS handles polling for them, at an approprate slower polling rate, that does not interfere with the rest of the operation of the machine.
Re: Offcoding device drivers
Define appropriate slower polling rate? I mean, certain drivers polling can be slow, and I mean really slow without issue. Other drivers may have to poll very fast, how does your OS know how quick to check them? Can the driver tell the kernel the polling speed or frequency, or does the kernel just assume the polling is infrequent? Does it guarantee to poll at a certain rate so the driver can be written accordingly? I am just asking some questions that are important for someone writing a driver. Obviously there are certain cases when polling every 500ms is plenty, while other cases a 500ms delay is unacceptable. What about things that rely on timing (for example, respond within 10ms after a status is set to send a value, what if you don't catch the status until 100ms and miss your response window time?) I know these circumstances typically use interrupts for this exact reason, but it can still be an issue from time to time. Not saying this is a bad idea, but it needs to be cut and dry for the driver dev's exactly how the kernel is handling the polling, which means more information for the person writing the drivers to worry about, and it also makes cross-compiling more difficult (although, filling in a polling function wouldn't be "that" difficult, and the function could easily be emulated/replaced).
Re: Offcoding device drivers
Yes, my OS is going to guarantee a "real time" response rate of 1 millisecond for all tasks with a realtime priority level -- and for most tasks under normal load. If you think you need to poll faster than that, do it yourself -- but the OS may swap you out to deal with other real time priorities, so you may be SOL on occasion. There is no way to achieve perfection, of course.
Re: Offcoding device drivers
I know the NeXT kernel did this, I would expect IOKit in OS X to do the same...Everything was abstracted - buses, device classes, etc...a typical disk driver would only need to send specific commands to the device; timing, resource management, etc were all managed at lower levels...it was quite nice really, you may want to look into old NeXT kernel documentation for ideas.
Re: Offcoding device drivers
Sounds pretty nice, what about things like a timeout, or interrupting the wait state to do something else? (Like a cancel button was hit, so no reason to keep polling), or a timeout period, so if no response in 10ms, then the device isn't responding, etc. It sounds like a good idea, and if implemented properly can help out as a whole, the kernel knows a lot more about what's going on than a single application/driver so I can see how it'd be useful.