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