Hi, > I don't want to argue with you, now. I read the ml and know there have > already been long discussions. For me it looked like both the pros and > the cons always found an answer, I don't want to begin that again, as > I think it will be more or less the same conversation.
Strange -- I'm under the opposite impression... In fact, there has been a single reply to my proposal, and zero answers to my followup. I actually wish there *was* some serious discussion. BTW, Peter's answer pointed out a number of shortcomings in the specific of my proposal (which I tried to fix subsequently), and also contained a number of statements questioning some of the advantages I listed on the premise that he doesn't consider them terribly useful. I found nothing in Peter's mail fundametally objecting anything in my proposal. (Plese tell me if you think I've overseen something.) And, to be honest, it would surprise me if there was -- considering that I discussed the basics of my idea with Peter even before actually writing it up. So far, the only serious objection to my proposal people repeatedly voiced is RPC performance -- and this is a misunderstanding IMHO. As explained in the previous mail, we can use custom RPC protocols as a shortcut wherever we actually experience performance issues, making it just as performant as other solutions. (In my understanding, deva would actually even impose some overhead, as any communication between applications and drivers would take an additional hop over deva, not necessary when the drivers are accessed directly like in my proposal...) > I could say that it was planned to wrap the driver tasks into hurd > tasks, That would be the wrapping and emulation I talked about... > I could say in my idea it would be possible to run multiple OS at the > same time, as all resource management is done through servers that are > only once in a the system. > > I absolutely agree with you that drivers are no aliens and must to be > handled in a ordinary way, actually 1-3 of my argumentation don't > really affect my mind, the fourth was what decided me to rethink. If so, you should rethink again. 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. At least that's my understanding. Please tell me if you see some flaw in my reasoning. -antrik- PS. I've written up some thoughts on one of the considerations that drive my preference for POSIX level drivers (and IMHO should generally be taken into account when designing Hurd mechanisms), at http://tri-ceps.blogspot.com/2005/08/design-by-bulldozer.html _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
