Re: New thoughts about deva/fabrica

[ness]

> > 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.

Oh, I'm sorry. I read your first post about the proposal and the answer 
and your answer and found no next answer. But I tought I didn't find it 
(I hadn't found out lists.gnu.org has some html interface, yet :D) and 
asumed the discussion had to go on this way long.

> > 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...

No. 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). But that would affect my multi-os-idea.

> 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.

>>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.
I am actually, I am. But I'm not sure it's right. (I now try to explain 
why I thought posix drivers would be wrong, maybye it's a bit hard to 
understand). When I first read the original driver proposal, I was 
confused: why do we plan an insular ddf, if even the most initial system 
servers use hurdish stuff lke caps and could even use the c libraray? 
(So you see, posix level drivers seemed straight forward for me.) Then 
the multiple OS idea came in my mind. So. mentioned the drivers should 
be shared between multiple os above l4. For me, that was the explanation 
 why we don't use posix level drivers. But I am (and always was) unsure 
whether it's worth it. But I thought: the ddf proposal is right, why 
should it be there if not, the one who wrote it and the "community" are 
sure about why it has to be this and not another way. And there are 
already shareable drivers (kenge and/or l4env IMHO).
So let's say, antrik proselytized me.
--
-ness-