Re: drivers for l4-hurd

[Peter 'p2' De Schrijver]

On Fri, Nov 29, 2002 at 01:56:04PM +0100, Marcus Brinkmann wrote:
> 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

Only the bus drivers would need to implement this. Probably a lot of the
common code can be put in a common library, something like libdevfs. As
all these things live in the control plane, the possible somewhat larger
overhead is not an issue. 

> libstore to access block oriented devices, and storeio to provide direct
> filesystem access.
> 
> > 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).
> 

All device drivers need a rendezvouz in the filesystem because it should
be possible to access them remotely in a transparent way. Ie. it would
be very nice to be able to directly access a serial port, or a scsi device 
on another machine without having to write special programs and
implement another wire protocol. I fondly remember my AIX/PS2 days where
I could write a bunch of floppies simultanously on all machines in the
room :) Obviously having a rendezvouz in the filesystem is not enough to
solve this problem, but it makes naming easy.

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

I'm not convinced device drivers need their own namespace or lookup
functions. Device drivers are not so different from any other
services such as a tcp/ip stack or a filesystem. They access the
hardware directly to provide the service, but that's about the only
major difference. For me a device driver is just a program like any
other program :)

Cheers,

Peter.