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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 9 Feb 2015, Ian Campbell wrote:
> 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.
 
I don't have an opinion on whether the stubdom build system should be
in tree or out of tree, as long it can be used in OSSTest.

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