I have read some things about Linux drivers, but i cannot understand the situation. In order to write drivers for a graphics card or an ethernet card for example, you need a way to communicate with it. That means that the commands you write and which refer to the device -ioctl has to do with it maybe- must get a response from the device. I don't think however, that devices have software -at least the ethernrt NIC-and can respond... In simple words, how can a specific NIC C preprocessor directive affect the opearions it performs? Can somebody clear these things out? Maybe point me to a link? A link to a real-world example, would be a good idea.

The key thing (IMHO) to understand about device drivers in contemporary, multitasking/virtual memory operating systems (like Linux or Windows) is that, unlike in DOS, you (the .exe program) can no longer talk directly to the hardware.

In DOS, your .exe could reach right down and start poking memory addresses and reading I/O ports. In Linux and Windows, on the other hand, there is always (at *least* one!) level of indirection between you and the hardware. In both time, and space.

By analogy, it's like the difference between picking up the phone and calling a friend (or driving over to his house and talking to him), and writing a letter, dropping it in a mail box, and having the letter delivered to your friend.

In this analogy, DOS is the "telephone call" and Windows/Linux drivers are "mail the letter". Your program interacts with a driver (either by "standard" calls such as open, read or write; or by "extension" calls such as you might invent with your own ioctl); the driver interacts with the hardware (either asynchronously - when interrupted, or by polling, when your driver task happens to be scheduled by the kernel). You"post a letter" to the kernel, which delivers it to your driver. Your driver "posts a reply" back to you - again, delivered by the kernel.

My two favorite books on Linux device drivers are:

Linux Kernel Development, Robert Love:
http://www.bookpool.com/sm/0672327201

Linux Device Drivers, 3rd Edition (O'Reilly):
http://www.bookpool.com/sm/0596005903

Unfortunately, I'm not sure that either one really addresses your conceptual question.

I did a bit of googling and, despite the author's apologetic introduction, this gives a good "one page overview" of device drivers in general (and Linux device drivers in particular) that might help answer your question:

http://users.evitech.fi/~tk/rtos/wri..._device_d.html

Hopefully this response was at least *somewhat* helpful to you.

Your .. PSM

I don't know anything about device drivers, but just to show that intelligence in a device is not required
A simple RS232 port based on i.e. 8250 will never reply. You simply write to it or read from it. On the lowest level this is:
you tell the processor to write to / read from a specific address; I don't know the finer details how to do that in Linux but I assume that this is done by driver and kernel (as explained by paulsm4)
the processor will then
for write
1) place address and data on address and data buses
2) issue writepulse
for read
1) place address on addressbus
2) issue readpulse

When a write pulse is 'received' by the device, it will store the data. When a readpulse is received by the device, it will present the data on the databus and the processor will read it (before it removes the readpulse).

In case of a read, the processor will now have the data somewhere in its memory (accumulator, register).
If DMA is involved, a DMA controller (integrated or not integrated in the processor) takes the place of the processor and the result will not end in the processor, but somewere in memory.

From there, the kernel and the driver will pass it back to the application.


If a device has intelligence, the principle stays the same. In that case you write e.g. a command to the device. As a result the device can tell the processor (i.e through an interrupt) that data is avalable and the processor will read it as described above.
Again, on the lowest level there was no reply from the device.