I'm reading an introductory article about drivers and came about this quote:
"Once the device sends data back to the driver, the driver may invoke routines in the original calling program. "
I was wondering what this would actually look like(an example).
Eg. If I had a program that had the user type in something, windows would use a driver, which would get input from my keyboard. I don't understand how keyboard could cause the driver to invoke a routine from my program.
The essential purpose of "a driver" is to abstract away the "messy details" of whatever it is "driving." The driver presents a standard interface to the rest of the world ... while only it confronts the "mess."
One of the fundamental things that it must be able to do, however, is to somehow tell you(!) that your request has now been completed, and that it either succeeded or failed.
However, as Martin has already commented, "there are many ways to do this."
The author of the article that you read was purposely simplifying the actual process in order to avoid confusing you – and this "little white lie" is perfectly reasonable. But if you're curious, it goes something like this:
• Your program wants to "perform I/O," so it makes a system call.
• The operating system constructs an internal "I/O request" and sends it to the layer within itself that is responsible for managing those requests – the layer which talks to "drivers." Meanwhile, it "blocks" your process, putting it in an "I/O wait" state because your program can't proceed until the I/O request is finished.
• At some future time, the operating system invokes your driver.
• At some time after that, the driver finishes the request and – by some means unknown to you – informs the operating system that it has done so.
• Now, your program's process leaves the "I/O wait" and becomes dispatchable again.
• Eventually, the process does get redispatched, and the first order of business is to – by whatever means – adjust the state of your program to correctly reflect this.
• Then, your process – which had been running in "kernel mode," "goes back to userland," satisfying the system call in what your program perceives as a simple "return from subroutine."
"Whew!" But: "an everyday bit of magic for any operating system."
It depends on the driver model of the particular operating system. The interface specification. Possible techniques used are callbacks, memory buffers, interrupts and signaling mechanisms. Driver models may change over OS versions, which is good for business (you will need new hardware). The OS vendor will tell you it is for security, which is probably true but it sucks nonetheless.
Communicating with driver software in both a reliable and a safe way is hard. You want to delegate work to 3rd party software but you do not want that software to do things you do not want it to do or disrupt the system in any way. So the interface has to be a bit more complicated than it technically needs to be to just work. Trust and/or validation/certification is an issue.
