Re: drivers for l4-hurd

[Marcus Brinkmann]

On Thu, Nov 28, 2002 at 09:26:50PM +0100, Peter 'p2' De Schrijver wrote:
> 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, ...

Well, at that level what you said is just a nice way to say: We don't have a
filesystem, but rather just a hierarchical namespace.  ;)  And of course in
the Hurd the main namespace is the filesystem, but that expects that the
Hurd is up and running, and I think that there are good practicle reasons to
not think "filesystems" if you think "device drivers", and those are the
bootstrap case, and the conglomerate of libraries you get to suck in if you
actually do filesystems in the Hurd.

Now, if you just use this analogie of namespaces, and if you also think
about a potential separate top level layer that is implemented in different
processes than the actual device drivers that can be used to manage the
device drivers (ie, just like a separate procfs that would use the libps
library nd thus the proc server to provide the data), then that is certainly
all fine and dandy.  My argument is less about abstract analogies and more
about pure pragmatical aspects of the actual implementation.

> > 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, ... . 

Oh, yes, I don't want to give a premature answer.  As repeatably said, my
message is that an answer should not be given now ;)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/