Re: [Xen-devel] On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15)

[Antti Kantee <pooka@xxxxxxxxxxxxxx>]

Ian,

Thank you for the explanations.

Hmm.  (not replying to anything specific)

My guess is that shared libs won't be the biggest problem.  I'd find it 
extremely surprising if you can take a Linux (or any other !NetBSD) 
packaging system and discover the dozens of dependencies of QEMU to not 
contain any "'isms" which do not apply when building for what is 
essentially a NetBSD target.
I don't know how Wei Liu built his QEMU, but I assume it was by farming 
a lot of --disable-stuff.  That's what I'd do and somehow find a way to 
ship the result.  The requirements for stubdom QEMU and /usr/bin/qemu 
are IMO too dissimilar to stuffed into the same box.  By my judgement 
(which may be wrong), almost none of the dynamic dependencies of QEMU on 
a regular Linux system apply for the Xen stub domain use.  If the goal 
is to get a reduced footprint qemu, bundling unnecessary clutter is in 
direct conflict with the goal.  Besides, trying to get e.g. libsystemd 
to build or work with [a NetBSD-API'd] Rumprun will most likely earn you 
a ticket to the loony bin.
So while I think I understand your predicament (you need to sell the Xen 
improvement to distros which means playing by their rules) and the 
temptation of reusing existing packages for the job, I seriously doubt 
the approach will lead to a sensible result.  That, of course, shouldn't 
stop you from trying.  If the result of your experimentation matches 
your hypothesis and shared libs is the main problem, I'll figure out a 
way to make it work on the Rumprun side of things.
If you truly decide you need to use existing Linux infra, I'd start down 
that track by bolting a Linux userspace environment on top of the 
"kernel only" Rumprun stack (which could/should more or less work thanks 
to syscall emulation).  Of course, you'd need to do the same for FreeBSD 
and every other system you want to support, so it's not a free ticket 
either, but by my guess at least a cheaper one.
Anyway, I only have guesses.

  - antti

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel