Re: New thoughts about deva/fabrica

[olafBuddenhagen]

Hi,

> > (Actually, this is probably a serious downside of the deva/fabrica
> > proposal. For those that aren't tracking it: Neal is working on a
> > nice resource management framework, in which applications, in a
> > hurdish manner, announce their own resource needs, and the manager
> > fills them as good as possible while keeping fairness, using a
> > market-based approach. Being among the most performance-relevant
> > tasks in the system, with real-time behaviour and all, the drivers
> > obviously need to make extensive use of the possibilities offered
> > here. However, this resource management interfaces will be
> > inherently Hurd-specific (or at least I see no feasable way to make
> > it generic), thus defeating the whole idea of a system independant
> > driver framework...)
> 
> The resource framework can be used by any l4 process and is by no
> means hurd specific.

Sure, the resource management framework can be used by any L4 process,
just like the memory managment framework, or the capability framework,
or, well -- the device driver framework...

Come on, when the other systems are reusing large parts of the Hurd
functionality, at some point it just starts being silly to consider them
independant systems at all, rather than just subsystems running inside
the Hurd framework; and trying to make the driver framework or any other
part of the Hurd less Hurd-specific is really pointless.

> Except that filesystem semantics are generally very inappropriate as a
> driver interface. POSIX style filesystems generally deal with byte
> streams, while drivers almost always work with some form of blocks
> (network packets, disk blocks, ...) While you can quite easily map a
> byte stream into packets, the reverse is much harder as you need to
> delimit ('frame') the data. The normal POSIX read/write functions
> don't do this, which makes them inappropriate as an interface for most
> devices.

For the record: In the meanwhile, we had some discussion on IRC. I
couldn't convince Peter that it's more useful to extend the POSIX/Hurd
interfaces, than creating a completely different interface for drivers;
and he couldn't convince me of the opposite.

Nevertheless, we engaged in some productive conversation on what
specifically needs to be added to POSIX/Hurd interfaces to make them
useful for drivers (which I very much hope we can continue), in
particular regarding the I/O interfaces. I've written up some thougts on
http://tri-ceps.blogspot.com/2005/08/unite-and-conquer.html , and will
try to incorporate the input into my proposal.

-antrik-