Device Drivers - How do they work?

[Sentient]

Im completely confused as to how device drivers could/can work.. help??

I've read about as much code and documentation as my brain will handle on the subject, and I'm still not getting the whole picture.

I see implementation which use the open, read, write, close -style of device driver, but I don't understand how they actually work with requests.

My current train of thought is... (And please feel free to correct my thinking, because I am truely lost at the moment)

Device drivers cover everything from graphics cards to network cards, pci devices in general, keyboard, serial ports, parallel ports.. the list is really endless.

What I don't understand is how one interface can work for all these different devices (Perhaps this is where my understanding is flawed?)

On top of that, if you have a device driver for a hard disk controller how does it know that there is a file system attached?

If it "program -> filesystem -> device" or "program -> device -> filesystem", and how do they all link together.

I realise this is a far-reaching question, and I'm not expecting the holy-grail of answers, but a few suggestions or comments to give direction would be appreciated.

Cheers

[Legend]

Well this actually where you start designing your OS

the open, etc. function api is unix-style afaik.
for example you can play sounds under linux by opening /dev/soundcard (with open) and write data to it (with write) and then close it. (Worked at least for me, might have changed with the changing api). If you want to set the playback rate and other parameters you got to use ioctls calls ^^

The basic device driver is a piece of hardware. But you might want to have a Graphics Driver, a Keyboard driver, etc. all with a special API.

And I guess a harddisk driver should not need to know that a filesystem is attached. It should load and write blocks on the harddisk. A filesystem should know on which harddrive it works, and the application should know with which filesystem it works (well, you might put a virtual file system layer inbetween)

So, the program will call a function to load bytes from a file, which will be handled in the filesystem, which itself calls a function in the harddisk driver which will read some blocks in.

How you call functions in drivers now is one other question! ^^

But you could do it in many different ways

[Sentient]

I'll ignore block devices for the sake of simplicity - once i figure out the general how-it-works I'll be able to get block devices working anyway.

I'll stick with your soundcard example.

Assuming my driver supported open,write,close and an "ioctl" function - it would be possible to control every aspect of the device?

In this example, write simply sends data to the soundcard's data channel - and open/close give you a 'file handle' kinda thing just so it know where the data is going.

Seems simple enough.. but what about the IOCTL function. It handles everything else. This is what I figured from looking at Linux source code, but it still confused me, because the IOCTL function could handle nearly everything. I could see it being used (in your example) to control the hardware volume, expected data format, dma setup, playback rate.. a LOT of things.

This is the bit I'm really confused on.

If the IOCTL accepts a "->command" to identify the type of command being requested.. should every command be in an API specification? otherwise 2 different soundcards could have different "->command" values for all their functions.

Assuming that this is the case, then do you need to specify "command sets" for every type of hardware?

Sorry if this is a lot of questions.. but it seems to be an important part of any system, and I'd like to start off in the right direction.

[knicos]

You have the right idea about ioctl. Everything u said is correct.

In my os i have a control function which accepts commands, and as you pointed out, every driver could have different commands to do things, so I have set out a standard set of commands used by every device driver. But obviously there are some specific commands, these should be kept standard for device types, eg sound card, which would have its own set of commands.

Yes, each device driver only needs open,close,read,write,ioctl, but functions such as create,destroy files and devices may be usefull.

[Sentient]

Thanks guys for clearing that up for me... time for me to try out this new found information.

It would seem that drivers work as I expected. I was just confused by not having seen any "command sets" defined in other source code. Perhaps I was just looking in the wrong places.. I will go dig deeper.