All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antti Kantee <pooka@rumpkernel.org>
To: Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Debian Xen Team <pkg-xen-devel@lists.alioth.debian.org>
Cc: rumpkernel-users <rumpkernel-users@freelists.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George.Dunlap@citrix.com
Subject: Re: On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15)
Date: Wed, 9 Sep 2015 13:42:38 +0000	[thread overview]
Message-ID: <55F0374E.4060003@rumpkernel.org> (raw)
In-Reply-To: <1441797308.24450.298.camel@citrix.com>

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

  reply	other threads:[~2015-09-09 13:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08  9:24 Notes from Xen BoF at Debconf15 Ian Campbell
2015-09-08  9:41 ` On distro packaging of stub domains (Re: Notes from Xen BoF at Debconf15) Ian Campbell
2015-09-08 15:03   ` Antti Kantee
2015-09-08 16:15     ` Ian Campbell
2015-09-08 16:26       ` Samuel Thibault
2015-09-08 16:37         ` Ian Campbell
2015-09-08 17:09           ` Samuel Thibault
2015-09-08 18:38       ` Antti Kantee
2015-09-09 11:15         ` Ian Campbell
2015-09-09 13:42           ` Antti Kantee [this message]
2015-09-08  9:47 ` Notes from Xen BoF at Debconf15 Jan Beulich
2015-09-08 10:15   ` Lars Kurth
2015-09-08 10:15   ` Ian Campbell
2015-09-08 10:39     ` Jan Beulich
2015-09-08 10:49       ` Ian Jackson
2015-09-08 10:55         ` Jan Beulich
2015-09-08 14:52           ` Doug Goldstein
2015-09-08 14:49 ` Doug Goldstein
2015-09-08 15:24   ` Ian Campbell
2015-09-17 10:06   ` George Dunlap
2015-09-16 13:20 ` Ian Campbell
2015-10-05 15:37 ` Ian Campbell

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=55F0374E.4060003@rumpkernel.org \
    --to=pooka@rumpkernel.org \
    --cc=George.Dunlap@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=pkg-xen-devel@lists.alioth.debian.org \
    --cc=rumpkernel-users@freelists.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.