Re: L4::BSD, Subclass your OS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> You might also want to look into pre-virtualization [1].
> Pre-virtualization has not yet been applied to FreeBSD because the
> FreeBSD kernel heavily makes use of segmentation, and this still
> requires a bit of tweaking.  You might be able to apply it to the
> other BSDs, though, and perhaps also to Darwin

I originally thought of FreeBSD because from most of what I can tell,  
the kernel is stablizing now that the GEOM and SMPng have gone into  
the tree, and have been there since RELENG_5. While I think NetBSD  
and OpenBSD are both due for some reasonably big changes like  
DragonFly's been undergoing since...forever :P (great changes, but  
DragonFly is probably too much of a moving target right now thanks to  
mdillon :-P)

I've given thought to NetBSD, because I really like how strict NetBSD  
hackers are on adhering to their own clean code standards, and it's  
very portable, so I think it's a good alternate.


> Unfortunately, the people most familiar with the pre-virtaulization
> environment (in particular Josh) are pretty swamped with work right
> now, so you can probably not expect too much hand holding.

Another great link, this seems to really address most of the concerns  
that I'd hit later on once I got so far. The question that I'm  
running up against when discussing this with fellow hackers is as to  
how the L4-VM (or something like L4Linux) environment would handle  
very low level calls, like fork, poll, or even disk access from the  
at all from the host OS' I/O drivers? Does the patched Linux kernel  
simply translate all those calls into calls straight into L4, and how  
does it avoid collisions with any other (possible) host OS' that may  
be trying to access similar I/O devices, and or real time processes  
that are running in L4's user space along side the host OS (Linux)

Once the topic of virtualization comes up, I start to think about  
threading problems in a whole different arena, with the same scary  
undertones. Can the microkernel remain real time, and allow various  
different user land processes concurrent access/control to I/O  
devices, or is it simply first come first serve, and the L4 kernel  
will simply block other processes, leaving a host OS to wait for an I/ 
O device to "unblock" so it can access it? Or even worse, does it  
just not execute things real time in regards to IO?

There's a lot of documentation here, I'm just not certain where to  
look in regards to how hardware access occurs from the host OS kernel  
to the l4 kernel, and vice versa, as well as possible IO concurrency  
issues. Feel free to point me in the right direction :)


Cheers, and thanks a lot for the tips

- -R. Tyler Ballance
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFEY5/tqO6nEJfroRsRAoVFAJ9Ml9XgyBmiG4fEWQWs5+qdxX6Y/ACfdLSY
eAShD4Q5hboIKdWRy9OkrqM=
=b5s2
-----END PGP SIGNATURE-----