Re: drivers for l4-hurd

[Marcus Brinkmann]

On Thu, Nov 28, 2002 at 09:07:50PM +0100, M. Gerards wrote:
> > You definitely don't want to actually go through several process and
> > filesystem layers in the communication.  Look at how careful libstore is
> > written to not really go through /dev/hd0s1 etc in accessing the filesystem
> > data.
> 
> You only have to go through the filesystem once AFAIK. The driver will give 
> you
> a object handle.

I don't think the proposals so far where specific enough to really say it is
one way or the other.  My comment was just a general one:  It's a good idea
to keep it simple and small.  In particular if you want to run it in the
small address space area of L4, and if you want to keep it portable to other
L4 based systems.

> > 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.
> 
> You mean like the linux does with modules?

Yes, this is what I mean.

> I assume you want to put all drivers in one address space.

No, that is not what I am thinking of.  I am no expert at all when it comes
to device drivers.  But I don't think you need much flexibility when it
comes to, for example, IDE.  So you just have an IDE bus driver and drivers
for the few IDE device types that are out there in one "monolithic" program.

Having one process for each IDE device and one process for the bus just
sounds like a lot of modularity and encapsulation that nobody really needs
and just hurts you in design cost, complexity, and performance.

> Isn't this a very monolithical solution? If one driver
> crashes the whole system can go down under with it. 

If your IDE hard disk driver crashes, you would lose all IDE devices. 
That's an acceptable cost, I think.  Esp. if you allow one process per IDE
bus, for example.  In real life it's either so important you just don't want
it to crash, or it's replacable in larger pieces (ie, you have booted from
SCSI disks).

My main point is that there is no dogma.  There is no dogma that
encapsulation and Hurdish concepts are inherently a sign of drug abuse, but
there is also no dogma that you have to apply them down to giving each bit
in the universe it's own object handle ;)

In particular, the last thing I would worry about in a device driver
framework is filesystem access to the driver structure.  It can not be used
by the bootstrap filesystem anyway.

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/