Re: New thoughts about deva/fabrica

[olafBuddenhagen]

Hi,

> It was planned that the ddf asks deva if it wants to create a new
> task. And then so. mentioned deva could easily return hurd tasks
> (instead of l4 tasks).

I don't quite see why or how the DDF would decide whether a user-visible
"ordinary" task is created or not. All driver tasks should be hurdish,
just like others. But well, this is a side issue.

Of course, deva can manage Hurd processes for the drivers, serving as a
proxy. And handle signals, and file permissions, and users, emulate
hurdish process startup; and so on. The point is, all of this needs to
be implemented explicitely, and none of it is simple. It means wrapping
and reimplementing large parts of the Hurd functionality.

> >Maybe I was unclear; but the essance of the last part of my mail was
> >that the provisions necessary to allow multiple parallel OSes are
> >quite independant of the actual driver framework; deva doesn't help
> >here at all. The sharing can be implemented just as well with my
> >proposal.
> 
> That's the only part I don't understand. If we want to allow multiple
> os, there are 2 ways. a) one os uses the one, another os another
> resource. this would be OK for a monitor, but rubbish for a hard drive
> b) they share the drivers. And I don't see a way implementing b) with
> posix level drivers.

OK, I'll try again.

To share drivers/devices between multiple higher-level systems running
in parallel, you either need the driver sybsystem to be standalone,
implementing all necessary system functionality itself. The device
sharing is implemented either in the drivers themselfs or in some layer
above. Now the (shared) device access functionality is exported to the
systems running on top.

Or you have the drivers running as part of a complete OS (in our case
the Hurd), using it's features. The sharing is implemented in the
drivers or a layer above them here also; the device access functionality
is used both by the device hosting system and exported to the other
systems running in parallel. (Probably wrapped in some more generic
interface before exporting, so the other systems don't need to implement
native Hurd interfaces to access the drivers.)

The difference is that the second approach is much simpler, as we can
use all the existing Hurd functionality for the drivers. On the
downside, the drivers won't work outside of the Hurd -- the other
systems can use them only if we have Hurd running.

At this point, it should become obvious that the possibility of sharing
devices between systems running in parallel on the one hand, and the
possibility of reusing drivers in systems running standalone, are
*completely orthogonal* -- implementing one of them doesn't enable, or
even help with, the other.

The deva/fabrica proposal concentrates on reusing drivers in standalone
systems; it doesn't care about sharing drivers. Of course, such sharing
could still be implemented on top of fabrica perfectly well.

My POSIX level driver proposal trades fabrica's possibility of reusing
drivers in other standalone systems, for the simplicity and power of
using Hurd functionality directly. (Which is much more useful IMHO...)
But just like fabrica, it allows implementing device sharing on top of
it perfectly well.

I hope this clears things up a bit, not confuses you even more...

-antrik-