Re: Device Driver Framework (attached thesis proposal)

[Michal Suchanek]

Hello

On 1/22/06, William Grim <address@hidden> wrote:
> Thank you very much for your thoughts Tom.  I'll review my proposal with
> your new input and see if I have answers to your thoughts in there or if I
> need to add them.  About the bus drivers, that is actually one area I'm not
> well versed in when it comes to this proposal.  Therefore, I'll spend more
> time learning about why deva did that and check designs from Linux, etc to
> see how I might implement those well.  Mainly, about the bus drivers, I
> guess I'm mainly confused as to if PCI, AGP, etc are in separate logcal
> address spaces; if that is the case, then I can see how having dedicated bus
> drivers can help.  However, if everything is reachable via a single address
> space, then I am unsure why you need an AGP (or other) bus driver when the
> driver itself could just access addresses directly (assuming it has the
> proper capabilities).

Dedicated and separate bus drivers are a good idea in my view. In
current kernels like Linux you get (optional) support for various
buses like PCI, PCI-Express, ISA, and various AGP bridges. ACPI is
usually not listed as a bus but it is used to configure the pci and
legacy devices on many sytems.
You usually do not want all of that, and loading support for AGP
bridges separately makes some sense - you do not need the graphics
acceleration on all systems all the time.
Another examples of buses are IDE, SCSI, SATA, the floppy controller,
USB, FireWire. Drivers for these should be certainly separate.
It could be possible to write a very separated USB driver that uses
the services provided by a PCI bus driver. Depending on the properties
of the PCI bus we migh need an USB driver that is trusted not to lock
up the PCI bus.
But there is no reason why the USB driver cannot completely control
the drivers that attach to the USB bus. And there is no reason why the
device drivers cannot have their own access policy. It is probably
better to implement the policy outside of the actual driver but it may
use some arbitrary authentication helper. No need for centralization.

Thanks

Michal