[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: drivers for l4-hurd

From: Peter 'p2' De Schrijver
Subject: Re: drivers for l4-hurd
Date: Thu, 28 Nov 2002 23:46:03 +0100
User-agent: Mutt/1.4i

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]