[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC 7/7] libxl: Wait for QEMU startup in stubdomain

On Fri, 2015-02-06 at 17:23 +0000, Stefano Stabellini wrote:
> > 
> > One of the main issues outstanding from when Anthony originally posted
> > his patches is how we want to go about building this?  I honestly do
> > not know how well the current dracut-based approach to building the
> > root image will work across various Linux distributions; perhaps it
> > will be OK, since all of the libraries that dracut will siphon in will
> > have to be in place to meet the build requirements for QEMU to begin
> > with. 
> >
> > However, I have zero knowledge about ARM-based Xen or where
> > NetBSD is used for dom0, and how they might affect the decisionmaking.
> > I also do not know what lessons have been learned from building other
> > stubdoms, rumpkernel, or Mirage that might inform these decisions.
> > In other words, what do you see as a sensible build scheme?  The
> > approach taken in the patches strikes me as too hacky for release
> > quality, but maybe it is OK...
> It looks OK to me but I am not an expert in this kind of things. I'll
> let Ian Campbell and Ian Jackson (CC'ed) comment on it.

I'm not at all keen on things like the use of dracut (or mkinitramfs or
similar) in Xen's build since they are inherently/inevitably specific to
the Linux distro they came from, so they often don't work (or aren't
even available on) other Linux distros and are an even bigger problem
for *BSD.

I've yet to see a solution for this which seemed satisfactory enough to
be included in Xen's system. Mirage, minios stubdoms, rumpkernels etc
all avoid this by not having a need for a rootfs.

But, it's not necessarily the case that the Xen project has to produce
the Linux stubdom binary as part of its build output. IMHO it would be
sufficient (for tech preview at least) if the tools would detect and use
a stubdom binary if it were present at some well defined path so long as
the for the runes to build the image were documented somewhere (e.g.in
the wiki, in docs/misc, in some script, etc). Then the problems of them
being distro/kernel specific are somewhat mitigated (e.g. a Fedora fan
can write dracut instructions, a Debian fan can write mkinitramfs ones
and a BSD fan can make it work with a BSD kernel etc etc) and we avoid
having to have rootfs construction code in Xen's build.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.