From: Jacob Gorm Hansen <jacobg@diku.dk>
To: Jerome Brown <jerome@concepts.net.nz>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: uClibc
Date: Tue, 21 Dec 2004 22:11:22 +0100 [thread overview]
Message-ID: <41C8917A.5070106@diku.dk> (raw)
In-Reply-To: <41C88D03.2090409@concepts.net.nz>
Jerome Brown wrote:
> What size does this run at? I am looking to make dom0 as small as
> possible, and run all the applications that I require under other
> domains, to allow moving them to other machines if required.
I would image this to be the sum of Xen, a XenLinux with the TCP-stack
removed, and a few hundred kilobytes of initrd with my tools.
> How does the XenLinux self-migration differ from the Xen managed
> migration? What are the advantages of each option. I have only just
> started to look into this, so am not stuck to a specific way of doing
> things at this stage :)
Self-migration means that the unprivileged domain uses its own resources
(pager and TCP stack are the main ones), to checkpoint itself onto
another host. There are pros and cons to both approaches, I refer you to
my SIGOPS European Workshop paper, available from
http://www.diku.dk/~jacobg/ for more details.
> How do the resources used differ? Is Xend currently in python? Is there
> a plan to change this? What has been the reasoning behind developing it
> in python?
I am not sure what the exact reasoning behind this decision was, but I
am sure other people on this list would like to comment. I rewrote all
my own tools in C a while back, something I do not regret at this point.
From what I hear dom0 with Xend needs 32-64 megs to run. In my setup 4
megs should be a realistic target.
> I'd love to help. I like the idea of a 'self installing' dom0 that sets
> up another control domain, thereby abstracting all the running processes
> into unprivileged domains for security reasons. As part of this I will
> look to create a HowTo document that details how I acheive this :)
See if you can get any of the stuff on my page to run (both sources and
binaries are provided), and feel free to ask questions if you can't
(though I am on my way home fairly soon).
Best regards,
Jacob
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
next prev parent reply other threads:[~2004-12-21 21:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-21 20:14 uClibc Jerome Brown
2004-12-21 20:36 ` uClibc Jacob Gorm Hansen
2004-12-21 20:52 ` uClibc Jerome Brown
2004-12-21 21:11 ` Jacob Gorm Hansen [this message]
2004-12-21 22:44 ` uClibc Kip Macy
2004-12-21 15:20 ` uClibc Jacob Gorm Hansen
2004-12-21 23:36 ` uClibc Jacob Gorm Hansen
2004-12-22 1:48 ` uClibc Mark Williamson
2015-12-19 9:18 uclibc Markus Volk
2015-12-19 9:34 ` uclibc Khem Raj
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=41C8917A.5070106@diku.dk \
--to=jacobg@diku.dk \
--cc=jerome@concepts.net.nz \
--cc=xen-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.