From: Georg Lehner <jorge-plan9@magma.com.ni>
To: 9fans@cse.psu.edu
Subject: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9
Date: Wed, 6 Dec 2006 22:27:52 +0100 [thread overview]
Message-ID: <87ejrcaf53.fsf@jorgito.magma.com.ni> (raw)
In-Reply-To: <13426df10612060859o3fc0d437jc77ca3e66090f277@mail.gmail.com> (ron minnich's message of "Wed, 6 Dec 2006 09:59:58 -0700")
"ron minnich" <rminnich@gmail.com> 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
next prev parent reply other threads:[~2006-12-06 21:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-06 16:59 ron minnich
2006-12-06 19:58 ` Richard Miller
2006-12-06 21:27 ` Georg Lehner [this message]
2006-12-07 4:32 ` Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver Lucio De Re
2006-12-07 5:01 ` ron minnich
2006-12-07 5:46 ` Again: (self)hosted Plan9? Was: [9fans] extending xen to allow Lucio De Re
2006-12-07 6:06 ` ron minnich
2006-12-09 4:21 ` Chad Dougherty
2006-12-09 11:21 ` Steve Simon
2006-12-09 12:43 ` Lucio De Re
2006-12-09 12:56 ` erik quanstrom
2006-12-10 4:55 ` geoff
2006-12-10 5:04 ` andrey mirtchovski
2006-12-10 20:16 ` Charles Forsyth
2006-12-10 20:56 ` Francisco J Ballesteros
2006-12-10 21:38 ` Charles Forsyth
2006-12-10 20:52 ` ron minnich
2006-12-06 21:38 Again: (self)hosted Plan9? Was: [9fans] extending xen to allow driver development in Plan 9 erik quanstrom
2006-12-06 21:55 ` John Floren
2006-12-06 22:31 ` erik quanstrom
2006-12-06 22:38 ` LiteStar numnums
2006-12-07 0:53 ` John Floren
2006-12-07 0:56 ` LiteStar numnums
2006-12-07 1:09 ` John Floren
2006-12-06 22:52 erik quanstrom
2007-02-08 11:46 ` Harri Haataja
2007-02-08 12:47 ` LiteStar numnums
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ejrcaf53.fsf@jorgito.magma.com.ni \
--to=jorge-plan9@magma.com.ni \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).