Re: New thoughts about deva/fabrica

[olafBuddenhagen]

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