From: Karim Yaghmour <karim@opersys.com>
To: Nuno Silva <nuno.silva@vgertech.com>
Cc: JustFillBug <mozbugbox@yahoo.com.au>, linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Cooperative Linux
Date: Mon, 26 Jan 2004 01:36:35 -0500 [thread overview]
Message-ID: <4014B573.1020703@opersys.com> (raw)
In-Reply-To: <4014A058.9080206@vgertech.com>
Nuno Silva wrote:
> That's xen. You can learn more here:
>
> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
For a UP system, Xen may be fine, depending on what you're trying to
do. If you're looking for a better VMware, then Xen is likely to fit
your bill. However, there are a few things to keep in mind when
looking at this sort of stuff. So, for example, Xen assumes that all
OSes are going to use the same devices for I/O: same disk, same
NIC, etc. It therefore implements lots of virtual devices for these.
But what if you wanted each OS to manage separate hardware? Also,
I'm not sure I want my OS instances to have to request memory on
a page basis with the nanokernel/monitor. Wouldn't it be just better
to reuse the existing work on the hotplug hardware (hotplug CPU,
hotplug memory, etc.) to have the kernels get/return hardware
resources to the nanokernel? Also, how generic is the virtualization
solution being examined? I've put some thought into getting a
virtualization architecture which spans UP, SMP, SMP-clusters, and
hard-rt, and wrote that down as a series of papers about Adeos. I
probably don't have the final answer, and there are probably many
things I haven't figured out in the papers I've written on the topic,
but you may want to take a look.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
next prev parent reply other threads:[~2004-01-26 6:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-25 19:35 [ANNOUNCE] Cooperative Linux Dan Aloni
2004-01-25 20:01 ` Karim Yaghmour
2004-01-26 3:40 ` Nuno Silva
2004-01-26 3:57 ` JustFillBug
2004-01-26 4:59 ` Ben Pfaff
2004-01-26 9:19 ` Christoph Hellwig
2004-01-26 17:00 ` Ben Pfaff
2004-01-26 19:44 ` Christoph Hellwig
2004-01-26 20:04 ` Omkhar Arasaratnam
2004-01-26 5:04 ` Karim Yaghmour
2004-01-26 5:06 ` Nuno Silva
2004-01-26 6:36 ` Karim Yaghmour [this message]
2004-01-26 11:35 ` Rik van Riel
2004-01-26 15:20 ` Karim Yaghmour
2004-01-26 11:32 ` Rik van Riel
2004-01-27 0:20 ` David Schwartz
2004-01-26 4:26 ` Dan Aloni
2004-01-26 5:01 ` Karim Yaghmour
2004-01-26 7:23 ` Dan Aloni
-- strict thread matches above, loose matches on Subject: below --
2004-01-29 5:57 Paul Zimmerman
2004-01-29 9:10 ` Dan Aloni
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=4014B573.1020703@opersys.com \
--to=karim@opersys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mozbugbox@yahoo.com.au \
--cc=nuno.silva@vgertech.com \
/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