Layered drivers

Function calls. Any function exported by the lower level module can be called by the higher level. Though in many cases you do it the other way around and have the hardware specific module register itself by calling a function in the module implementing the higher level.

That would be a bad design. (It would be possible, but it is easier to do things the right way).

Many. I think both the sound subsystem and the USB subsystem have a hardware independent module which is loaded first, and then drivers for specific hardware calls exported functions.

There are many network drivers partitioned so that the chip driver and the card driver are separate.

Also, the parallel printer driver and parallel port driver are layered.

Thanks for the replies!

I have a few questions below....

I am fighting an uphill battle here over the design. Why is that a bad design?

Hardware independent loaded first. I hadn't thought of it that way. He creates the /dev/something then fields the reads(), writes(), ioctls(). The read() blocks until there is data. The hardware specific driver registers only the ISR? The hardware specific driver seems to need to be called at least on the

write(), open(), and release(). Is that done via a call back or simply use an exported function?

The hardware specific ISR receives the data on read, queues it, then calls the module above to unblock the read and process the data. If there is not enough data to complete one packet, then the read reblocks and we do it again.

-- Posted via NewsDemon.com - Premium Uncensored Newsgroup Service ------->>>>>>

Thanks for your response!

Can you name files? I cannot figure out which is the printer driver.

Thanks again! Bill

-- Posted via NewsDemon.com - Premium Uncensored Newsgroup Service ------->>>>>>

Because reading a file in /dev/ or elsewhere implies a rather long and convoluted sequence of nested calls to functions in the vfs and on, before finally branching through a table of functions to do the actual IO on that particular /dev file.

In order to establish the necessary infrastructure for this you would be doing quite much the same as "the right thing" implies, putting pointers to functions in a structure and passing a pointer to that structure to a function that registers devices and assigns major device numbers. It would be just a long detour.

Then comes all the complications of assigning a user as owner of the file in /dev, a mode, etc. The kernel is generally agnostic of the layout of the file system. That layout is a userspace policy. The kernel should work equally well if you have the device nodes in a directory called /devices, or /Geräte, or /ordenador/aparatos or whatever, or spread around in a thousand places.

It is just so much easier to have the lowlevel module call a function in the higher-level module, when the lowlevel module is loaded, saying "Hello, here I am, and these are my functions."

-Enrique

They are in the device driver directory.

Parallel port is parport.c and parport_pc.c.

The printer is lp.c.

Thanks for you help!

-- Posted via NewsDemon.com - Premium Uncensored Newsgroup Service ------->>>>>>

Thank you for your help - The powers that be have been persuaded!

Much appreciated! Bill

-- Posted via NewsDemon.com - Premium Uncensored Newsgroup Service ------->>>>>>

Thanks so much for your help!

Bill

-- Posted via NewsDemon.com - Premium Uncensored Newsgroup Service ------->>>>>>