I'm a little confused on how to implement device drivers. I've been reading all the resources I can find on the subject, but none seem to cover it properly.
At the moment, I am working on the serial port / mouse device driver.
I know how to program the serial port, and read the data for a standard mouse.
What I don't understand is the device driver side of things. Does the app opening the device (via the driver) have to poll it to see if data is available?
Or does the device driver send messages via the kernal to the app that controls the device driver to tell it data is available.
I know how to implement both these methods, but which is better.
I would tend more toward the driver sending messages as an attempt to prevent buffer overruns on the hardware. But if the controlling app still doesnt request the data then overruns will occur. In the case of a mouse, simply throwing out data or ignoring incoming data will result in either a) mouse lag (best case) or b) out of sync data (worst case).
Any ideas on device driver implementation would be greatly appreciated.
Device Driver Implementation
-
VE3MTM
RE:Device Driver Implementation
You can really do either, but event-driven is almost always more efficient than polling.
Normally how event-driven works is that the app calls a function (read(), for example). The system then checks the device's output buffer for data. If there's enough to satisfy the app, then it gives that to the app immmediately. If not, then it puts the app's thread to sleep and adds it to a wait queue for the device. Then, when enough data comes in to satisfy the app's call, the thread is woken up, and the data is returned.
One question though: how would polling put you at more of a risk for buffer overruns?
Normally how event-driven works is that the app calls a function (read(), for example). The system then checks the device's output buffer for data. If there's enough to satisfy the app, then it gives that to the app immmediately. If not, then it puts the app's thread to sleep and adds it to a wait queue for the device. Then, when enough data comes in to satisfy the app's call, the thread is woken up, and the data is returned.
One question though: how would polling put you at more of a risk for buffer overruns?
-
Sentient
RE:Device Driver Implementation
If an app doesn't poll the driver, it will buffer overrun (especially with a mouse on a serial port). But having said that, if an app doesnt read the data when it recieves a message to say the data is available, overruns may still occur.
So I guess the problem exists either way with a malfunctioning app.
So I guess the problem exists either way with a malfunctioning app.
-
Adek336
RE:Device Driver Implementation
I would do it another way. The driver itself computes the pointer position from reading the data from the hardware, and send any interested app the current position of the pointer.
In fact I never made it that far to sending the data to an app, so I don´t know if it would work.
Hope this helps,
Adrian.
In fact I never made it that far to sending the data to an app, so I don´t know if it would work.
Hope this helps,
Adrian.
-
VE3MTM
RE:Device Driver Implementation
Ever heard of realloc()? 
I'm only partially kidding, that's one solution. Personally, I'm all for event-driven device drivers. That's how mine works.
Another is to have a fixed buffer, and when it overflows you shove the oldest data into /dev/null, so to speak. It should be big enough that a well-behaved driver will never lose data, obviously.
My point is that there are always many ways to do something. Never say "I can't do it X way because Y will happen" for anything non-trivial. You can always get around Y and still do X. X is not always the best solution though.
I'm only partially kidding, that's one solution. Personally, I'm all for event-driven device drivers. That's how mine works.
Another is to have a fixed buffer, and when it overflows you shove the oldest data into /dev/null, so to speak. It should be big enough that a well-behaved driver will never lose data, obviously.
My point is that there are always many ways to do something. Never say "I can't do it X way because Y will happen" for anything non-trivial. You can always get around Y and still do X. X is not always the best solution though.