Re: drivers for l4-hurd

[Marcus Brinkmann]

On Fri, Nov 29, 2002 at 10:00:14AM +0100, Daniel Wagner wrote:
> I think creating a hierarical driver framework is very good thing,
> because then we can use the OO approach which was suggested few mails
> ago. I had a quick look into newbus. It seems very promising to steal
> some ideas. For example the interface for a bus looks like this 
> (kern/bus_if.m):

Sure, of course.  Look at OSKit, it's also OO and hierarchical.  Roland's
buswalk is used to find a driver in the hierarchy.  Just because it is OO
and hierarchical doesn't mean it should be a filesystem.

Maybe I should make myself clear a bit.  When I say something is a
filesystem, I mean that it implements the filesystem protocols fsys.defs,
fs.defs and io.defs.  That includes node management like filesystems do, and
as many of the standard RPCs as make sense, ie, dir_lookup, dir_readdir etc.

My gut feeling is that device drivers are at a lower level than the
filesystem.  We might end up with device driver access through the
filesystem, but that filesystem access does not necessarily need to be
implemented by the drivers themselves.  For example, currently, we use
libstore to access block oriented devices, and storeio to provide direct
filesystem access.

> I very like to use some code of the newbus, so we don't have to
> invent everything new and we get a working interface also. So if we
> use the newbus approach (which also in somehow the basic idea by the our
> draft) then we have a hierarchical system. So far nothing is
> really hurd specific. It is a logic order of the drivers. So any other 
> project could use this. It just depends how we represent in hurd. 
> 
> > 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.
> 
> Yes, that's a good point. But we need a roundevouz place where a translator
> like the pfinet attaches to the network driver. This could be still
> /dev/eth?. I could live with that. But I think then we have
> some problems with the hotplug devices. E.g if I don't need the
> pcmcia network card the driver should go away. But what happends to
> /dev/eth?, should it also go away? 
> 
> Unfortunatly I don't know how the linux does it and I guess the have/had
> the same problems. I will have to look at this to. 

You don't need a rendevouz place in the filesystem.  It can just be a global
object stored in the proc server, for example.

Currently, there is no /dev/eth? at all.  The devices live in their own
namespace, and are accessed through a different interface
(see device/device.defs).  Now, the current Mach interfaces are probably
not the best example :) they are way too minimalistic.  libstore and pfinet
know how to access the devices at their device layer (see libstore/device.c
and pfinet/ethernet.c).

Well, just start with the development of all your ideas, and if you end up
with a filesystem, it might just as well be one.  But I fundamentally
believe that you shouldn't start with the filesystem idea and work your way
down to the device drivers ;).  Device drivers are special enough that they
deserve their own complete subsystem, and that should include its own
namespace and lookup functions, I guess.  How we export that to the filesystem
level in the Hurd is an orthogonal question, I think, and is (very) partially
already answered by libstore, actually.

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/