Re: drivers for l4-hurd

[Peter 'p2' De Schrijver]

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

Small is always good :) 

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

I don't agree here :) You need to support the myriad of IDE controllers,
which all look alike, but are not exactly the same. You have to support
IDE DMA, which also depends on the host controller specifics. Then you
have drivers for HDs, cdroms, tapes, floppies, cdwriters, and probably
others. Then there is hotplug support (in most laptops you can hotplug
the cd/dvd drive for a HD for example). Then there is serial ATA...
For SCSI this becomes even more interesting. You have different
commandsets (disk, tape, cdrom, cdwriter, ...) and different transports
("parallel scsi", fibre channel, serial scsi, IP).

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

I'm not so sure it would cost you a lot of performance. You can pass
requests and data around by passing blocks of memory. I know this MMU
trickery costs TLB flushes. The hard thing is defining the right
interfaces.

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

So basically you want to be able to decide how the different components
should be split over ASs ?

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

Cheers,

Peter.