0

I am learning about device drivers, and based on what I know so far, if your application wants to communicate with some device, it cannot communicate directly with the port that your device is connected to (for example: a serial port). But rather, you should create a device driver that is allowed to communicate with the serial port, and then your application will communicate with the device driver.

Now my question is: when the device driver is sending data to the serial port, does it send the data directly to the serial port, or does the serial port itself have a device driver, and to send data to the serial port, your device driver have to send data to the device driver for the serial port.

The quote from this question is what made me think about this:

The driver for the serial port on your computer instructs your OS how to talk to the specialized hardware.

3

In a modern operating system, device drivers serve two purposes:

  • They are an abstraction layer
  • They move potentially dangerous operations out of user code and into trusted system services

It is important to remember these two purposes when you consider what is and isn't either necessary or advisable when you consider using device drivers. Now, breaking down your question into details:

if your application wants to communicate with some device, it cannot communicate directly with the port that your device is connected to

Right. This is because of the "potentially dangerous operations" part. Communicating with a serial port, depending on the exact hardware you're running on, requires:

  • either sending or requesting data on the "IO" signals of the processor or writing or reading from specific memory locations that are associated with the port
  • intercepting interrupt signals from the port to let you know when data is available, when its internal buffer is empty, etc.

Typically, these resources are shared between multiple ports, so if your process could do either of these directly, it would be able to interfere with any other process that might be using other ports. Therefore, an intermediary is required that will make sure it only performs actions that won't cause problems with other parts of the system. The device driver is such an intermediary.

But rather, you should create a device driver that is allowed to communicate with the serial port, and then your application will communicate with the device driver.

This is not usually necessary. Operating systems are supplied with serial port drivers, so you don't need to create one yourself. In general, user applications should never need to supply device drivers: device drivers are a system function that are associated with the hardware they run on, not the applications that want to use it. This relates to the "abstraction layer" purpose: there are multiple types of serial port, and the device driver knows in detail how to talk to the actual type that your computer has installed. Your application only needs to know how to talk to the device driver, and your operating system provides a standard interface that allows that without needing to know which exact driver is in use.

Now my question is: when the device driver is sending data to the serial port, does it send the data directly to the serial port, or does the serial port itself have a device driver, and to send data to the serial port, your device driver have to send data to the device driver for the serial port.

This isn't usually necessary. You only need one device driver in order to achieve both purposes:

  • The device driver is installed with the system so it can vary depending on what hardware is available, providing abstraction
  • The device driver is part of the operating system, and is trusted by the kernel not to allow applications to interfere with each others' operations

That said, there is one case that is similar to the situation you describe, where you may want to have an application-specific device driver which sends data to the hardware-specific device driver. That is if you have a device that you connect to the computer via a serial port, but which you want the application to logically consider as separate to the serial port -- perhaps because you may want to be able to produce a range of devices that have the same behaviour, but maybe there's a serial port version, a USB version, a parallel port version, etc. In that case, it may be worth creating a second driver that provides a second abstraction layer (in this case abstracting the details of how the external device is connected rather than how the port it is connected to works). One example of this (now somewhat relegated to history, thankfully) is the way you used to be able to get mice that connected via serial ports. These would have a driver that implemented the standard mouse protocols and which talked to the serial port driver to actually communicate.

  • Say I created a device that have one small light bulb that can be connected via a serial port to the computer. And now I want to create an application in Assembly that can tun on or turn off this small light bulb. How can I send data to the serial port? are there any special Assembly instructions that can be used to send data to a serial port that I can use directly, or should I call some OS function that will do that for me? I believe I should call some OS function (which will access the serial port without interfering with any other process like you said). Am I correct? – John May 28 '17 at 4:09
  • @John: yes, you would just make system calls to send stuff. The OS is a gatekeeper, all access to the hardware has to go through it, otherwise your process will get the axe. – whatsisname May 28 '17 at 5:50
  • @whatsisname So when I install a device driver (for example: a printer driver), the printer driver is not actually the one accessing the port the printer is connected to, but rather it is only talking to the driver below it (the serial/parallel/USB driver depending on the port type the printer is connected to). Am I correct? – John May 28 '17 at 6:56
  • Yes. For something like a printer, you would have an extra driver layer. But hardware that didn't have a common device type like that, you may find software accesses the port via the hardware driver, without an extra driver for the connected device type. – Jules May 28 '17 at 7:59
  • @John: Hardware has a tendency to have a "naturally hierarchical" structure (e.g. USB devices connected to a hub, connected to a USB controller, connected to a PCI bus); and drivers tend to mirror that structure (e.g. USB printer driver talking to USB hub driver talking to USB controller driver ...) – Brendan May 28 '17 at 15:48
0

Your question is worded a little confusingly, probably because you don't really understand it enough, but there isn't such a thing as a driver in the hardware, if that's what you were trying to ask. However, especially on desktop operating systems, device drivers are usually written in layers. The bottom layer works on only a specific chip or family of compatible chips, the next layer up maybe all chips from a manufacturer, the next layer up RS-232, the next layer up all character devices.

Then when you have a language that uses a cross-platform virtual machine, it will have it's own layer of serial drivers, and sometimes when people don't like the default API that driver provides, they will create an enhanced user-space layer on top of that which can be called a driver.

So the term driver is somewhat overloaded and context-dependent. They all abstract away differences in different serial ports, but without knowing the context, you might be talking about something that literally sets voltages on wires or just gives you something better than what javax.comm provides.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.