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- _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
