"ron minnich" <[EMAIL PROTECTED]> writes:
...
> We have an ok xen environment going. Why are we doing this? Per a
> certain person at xyz.com, we are looking at giving people a usable
> xen-based plan 9 environment, and at the same time letting them do
> driver work from Plan 9 by "poking holes" in Xen to let Plan 9 at the
> real hardware. Xen supports this, we think, although we have not got
> it going yet ...
>
> I already like the situation thus far, as Plan 9 under Xen is a ton
> faster than Plan 9 under qemu. You have to see it to believe it; if
> anything, the Xen advantage is better than it used to be. I was
> surprised.
...
I have a similar situation:
- Xen helps me run several Plan9's one the same hardware
- I can give my users a Plan9 environment without taking away the OS
they are used to work with
- Xen is much faster then Qemu, ok for production use
- as Richard Miller said: ".. the whole point of xen is that physical
devices become Somebody Else's Problem."
However I think that the same goals could be achieved more natural,
even faster, more stable and more generally aplicable if Plan9 could
be run (self)hosted.
The Hurd can be run as a user space process inside The Hurd. Made
feasable because of its multi-server nature: the Kernel almost does
not do I/O. Thus The Hurd allegedly can be debugged and developed
more easily.
I guess the Plan9 Kernel could be separated in two layers, the upper
one just doing "high-level" and 9P-protocol stuff, and a lower one,
providing the #-channel interfaces to the upper layer and doing I/O.
The lower layer could either be comprised of hardware drivers for the
real hardware, or a hosting layer which intermediates between the
block devices and memory managment operations of a certain hosting
operating system and the #-channel interface to the upper layer.
Maybe this approach could also clean up the duplication of code
between 9loader and kernel I have read about in some Plan9 document.
Hardware driver development could also be eased by this approach,
since it is probably easier to pass certain hardware through to a
Linux process (the hosted Plan9 instance), than to go through the
complexities of Xen-Hypervisor - dom0 Linux - domU Plan9 interaction.
And: I know that this approach probably would increase complexity and
reduce performance with respect to the current Plan9 kernel.
Initially I have started to browse the Plan9 kernel source code, Linux
kernel docs, x86 assembler manuals etc., but I realized very fast,
that my spare time will never be sufficient to spot out all required
points to get anywhere with such a project. However maybe there are
some folks out there who like the idea and have the knowledge to do
it.
Best Regards,
Jorge-León
