Re: drivers for l4-hurd

[Peter 'p2' De Schrijver]

On Thu, Nov 28, 2002 at 04:07:59PM +0100, Marcus Brinkmann wrote:
> On Wed, Nov 27, 2002 at 03:30:46PM +0100, Michal 'hramrach' Suchanek wrote:
> > Imho the translators should be configured passively so that they are started
> > when the device is needed.
> 
> I don't actually think you should start with filesystem integration here. 
> Adding filesystem interfaces to a device driver is opening a large can of
> worms, and you don't really want to worry about that.  Look at the proc
> server, it doesn't provide any filesystem interface, although it arguably
> could (/proc anyone?).
> 

A filesystem is a nice way to present a hierarchical structure such as a
bus topology. This does not mean that every interaction with the "files"
should happen using unix like open/close/read/write semantics.
Some operations will be generic, others will be bus specific. Generic
operations could be : get power state, set power state. Specific
operations for PCI could be : map BAR, unmap BAR, get IRQ, get
consistent memory, release consistent memory, map pci memory, unmap pci
memory,... Specific operations for USB could be : Submit URB, ...

> You definitely don't want to actually go through several process and
> filesystem layers in the communication.  Look at how careful libstore is
> written to not really go through /dev/hd0s1 etc in accessing the filesystem
> data.
> 

No. At least not in the data path. 

> Just a word of warning so that you don't fall for the old "if you only have
> a hammer, everything looks like a nail" trap.  Certainly you can make it
> look like a filesystem, but that doesn't mean it is useful or feasible.
> 
> In fact, I would think that for some things (Bus driver + device drivers)
> it's easier to have it all in one driver program with maybe dynamically
> loadable shared object modules.
> 

This split depends on a few things : speed of L4 messaging and memory
mapping, device throughput, CPU speed, ... . 

Cheers,

Peter.