| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Really really small xen0
> Does it even need an init.exe? or a mounted file system?
These are necessary if you're not going to try hacking in the kernel, purely
to stop Linux getting upset. The init doesn't have to do anything and the
filesystem can be empty (apart from the init). Using a suitable filesystem,
you can make the initrd really small.
> Couldn't the
> kernel just jump into a kernel thread xen idle loop? Would it then be
> possible to have this minimal xen0 linked in to xen?
You might be able to hack the init kernel thread to just block but it's not
clear there's much advantage over having a userspace init that just blocks.
You still might find Linux wants to mount *something* at boot, though.
I can check the mini init into the unstable tree as it might be useful to some
people someday.
> I guess there needs to be some way of communicating the parameters to
> the xen kernel.
Yeah. For the minimal driver kernels, we had the backend driver in the domain
automatically set up bridging, etc. For flexibility and cleanness, we now
set this up all from userspace.
We already have a generic control message framework for passing messages to
other domains from domain 0. We'd need to add some more message types in
order to issue bridge setup commands, etc.
> Is the ether bridging done in xen? or in domain 0?
Xen itself doesn't know / care about devices, the bridging is done in domain
0. The "backend" network driver runs in dom0 and creates a virtual ethernet
device to talk to each "frontend" network interface in an unprivileged
domain. The standard Linux bridging / routing code is then used to bridge /
route those virtual interfaces. So it all happens in dom0.
> Maybe
> it can be driven by an initrd in xen0.
You could put some extra tools in the initrd in the driver domain but you'd
still to figure out some way of telling them how to bridge / route new VIFs
as domains are started. I suppose you could hack Xend to issue commands to
the console interface, although that seems a bit skanky to me ;-)
> Could you then still have another privileged domain do status
> monitoring, and user domain startup/shutdown?
In principal you could get Xen (with some hacking to add the required
functionality to XenLinux / Xend) do something like this. This done, you
could be able to run a driver for each block / net device in a separate
domain and admin stuff in yet another.
Many of the pieces required for this are in place now. There is a bit of a
chicken and egg problem regarding how these domains get built in the first
place (how does the driver domain get built without the admin domain / how
does the admin domain load without the driver domain) but it's surmountable
(e.g. use some large initrds!).
This is quite interesting stuff, it's just not been as high priority as some
of the other features in the release.
HTH,
Mark
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home