Re: drivers for l4-hurd

[Peter 'p2' De Schrijver]

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

I think it should be possible to minimize the dependency on external
libs and use a ramdisk loaded by grub for the initial fs dependencies (I
don't think we need anything more then root fs translator, bus managers
for IDE and PCI, IDE disk dirver, omega 0 to mount /).

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

That would mean we have to make another API to do such fs like
operations as chdir, rmdir, mkdir, open, close, rm,. Obviously possible,
but we already have that no ?

> > > 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 ;)
> 

The API's should probably be designed so that drivers can share an AS or
live in a different AS. This would allow us to use seperate AS's when
developing/testing and move to 1 AS when speed is required.

Cheers,

Peter.