New thoughts about deva/fabrica

[ness]

[I hope I'm not too late...]
After I read antrik's proposal about "posix level device drivers" I 
thought that was a great idea. I spent the last 3 days reading mailing 
list archives, and now I'm unsure it is. Actually, most of the 
advantages listed there can be implememted in the original ddf proposal 
by Peter De Schrijver and Daniel Wagner. Second, while readin' the 
mailing list it tourned out for me that there're lots of disadvantages 
we have with posix level drivers, and not the smallest one is speed. 
Third, if u have a look at "conventional" drivers, there's no or very 
less need of libc functions. And fourth, there's a pragmatic reason: a 
microkernel allows to run multiple OS in parallel. And we shouldn't skip 
this great advantage. But I don't see a way to marry posix level drivers 
and OS independend drivers. And we need OS independend drivers, as they 
have to control multiple/parallel access. Actually, we're not able to 
run multiple OS, but that's not the problem. We CAN run multiple OS with 
little changes (make wortel boot 'em, and implement "our" physmem as a 
proxy to the global physmem). But if we want to keep the ddf OS 
independend, this has to be planned from the beginning. (The original 
proposal looks like it is.) The most important thing we'd have to 
consider is the management of multiple deva. Actually, it's a question 
of trust:
The ddf only trusts
a) itself
b) wortel
c) all deva
I'd propose an global wrapping server (as part of the ddf). It should
a) only communicate with wortel
b) wrap thread/task management (or should be notified at the creation)
c) be notified at task deletion (sth. like our task info caps)
d) based on c) export a task death notification system for parts of the 
ddf (this is essential for securety of w0 and o0, se next paragraph)
e) give information whether a task is trustable or not (is part of ddf 
|| is wortel || is a registered deva)
So it's main job is interaction between the ddf and the manager OS 
(wortel). All communication with the OS(') is done through (their) deva. 
 Communication is mainly loading new drivers. So if a new device is 
found, the plm has to ask all deva. So the main difference between my 
ideas and the original proposal is the strict severance between the 
manager OS (that is exactly 1 time runnin') and the real OS' (that are 
1+ running). We need well-defined protocols ddf <-> wortel And ddf <-> deva.
Second, I'd like to inspire beside the central IRQ server w0 a central 
port-I/O server o0 (omikron-zero). I see the following advantages: 
locking of ports, easy access (via inb/outb, inw/outw ...), and mapping 
if very fast access is needed. I'd be happy to implement both of 'em and 
 write an interface specification for the second. Of course this would 
need more discussion, first, but I hope we don't get stuck in endless 
discussions.
--
-ness-