From mboxrd@z Thu Jan 1 00:00:00 1970 From: Georg Lehner To: 9fans@cse.psu.edu Subject: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9 References: <13426df10612060859o3fc0d437jc77ca3e66090f277@mail.gmail.com> Date: Wed, 6 Dec 2006 22:27:52 +0100 In-Reply-To: <13426df10612060859o3fc0d437jc77ca3e66090f277@mail.gmail.com> (ron minnich's message of "Wed, 6 Dec 2006 09:59:58 -0700") Message-ID: <87ejrcaf53.fsf@jorgito.magma.com.ni> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: ebc8aed6-ead1-11e9-9d60-3106f5b1d025 "ron minnich" 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=F3n