From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain Date: Mon, 9 Feb 2015 09:07:13 +0000 Message-ID: <1423472833.23098.9.camel@citrix.com> References: <1423022775-7132-1-git-send-email-eshelton@pobox.com> <1423022775-7132-8-git-send-email-eshelton@pobox.com> <20150206111616.GD30821@zion.uk.xensource.com> <20150206145940.GE30821@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Anthony PERARD , Ian Jackson , xen-devel@lists.xensource.com, Wei Liu , Eric Shelton List-Id: xen-devel@lists.xenproject.org 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. Ian.