From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V3op9-0007PY-51 for mharc-grub-devel@gnu.org; Mon, 29 Jul 2013 10:53:23 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3op0-0007CU-86 for grub-devel@gnu.org; Mon, 29 Jul 2013 10:53:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3oot-0003he-M0 for grub-devel@gnu.org; Mon, 29 Jul 2013 10:53:14 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:39959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3oot-0003hI-GQ for grub-devel@gnu.org; Mon, 29 Jul 2013 10:53:07 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6TEqxZo022678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Jul 2013 14:52:59 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6TEqvgN025875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 14:52:58 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6TEqvXP014498; Mon, 29 Jul 2013 14:52:57 GMT Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jul 2013 07:52:57 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 342801BF4EA; Mon, 29 Jul 2013 10:52:56 -0400 (EDT) Date: Mon, 29 Jul 2013 10:52:56 -0400 From: Konrad Rzeszutek Wilk To: "Vladimir =?utf-8?Q?'=CF=86-coder=2Fphcoder'?= Serbinenko" Subject: Re: [PATCH] remove dependency on /boot/config-* in grub.d/20_linux_xen Message-ID: <20130729145256.GH5848@phenom.dumpdata.com> References: <20130715180006.GA2433@phenom.dumpdata.com> <51F19775.5060305@gmail.com> <51F2C4F7.30206@oracle.com> <51F2C7D0.2050500@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51F2C7D0.2050500@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:53:22 -0000 On Fri, Jul 26, 2013 at 09:02:40PM +0200, Vladimir '=CF=86-coder/phcoder'= Serbinenko wrote: > On 26.07.2013 20:50, konrad wilk wrote: > > > >On 7/25/2013 5:24 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote= : > >>On 15.07.2013 20:00, Konrad Rzeszutek Wilk wrote: > >>>Hey, > >>> > >>>There is a discussion on the linux-kernel mailing list in which the > >>>Linus states that "if you depend on any config file, you're broken > >>>by definition" (https://lkml.org/lkml/2013/7/15/368). > >>> > >>The world is broken by definition sometimes you just can't avoid bein= g > >>broken unless a good facility for your needs is supplied. In this cas= e > >>it would be a documentation on how to detect dom0 pv_ops. We could > >>ship a detector as a GRUB tool if appropriate documentation is provid= ed. > >One suggestion was to use readelf to see if the binary has an .Xen ELF > >note in it. But then > >that creates a dependency of grub tools on 'libelf' and that is probab= ly > >unwise for just one > >case. I guess one could write a grub-detection code without depending = on > >libelf to do this too? > > > >The .Xen ELF header is documented > >here:http://wiki.xenproject.org/wiki/X86_Paravirtualised_Memory_Manage= ment#Start_Of_Day > > > pv_ops kernel is not ELF. It's bzImage. This article doesn't apply > to bzImage. Duh! It certainly is. Thought the bzImage is decompressed and there is so= me form of ELF data in there, otherwise Xen wouldn't be able to load the Linux kernel and parse the .Xen.note entries. > > > >>>The 20_linux_xen does that however it should not do it. In all fairn= ess > >>>this check is a bit of old as pretty much any upstream kernel > >>>is being built by default from distros to boot with Xen. If it does > >>>not, Xen will print a message telling the user that Linux does not > >>>have the required components. > >>> > >>It depends on kernel config. Not everybody uses one-size-fits-all > >>major distro kernels (no offense for distros but sometimes you need o= r > >>prefer customized kernels). > >>What happens if one tries to load a kernel without pv_ops on top of > >>xen? Does he at least get a decent error message or just black screen= ? > >Yes, there is an decent error message on the VGA console. > >>Some distros increase xen_linux priority above those of standard linu= x > >>and it may happen that xen is inadvertently installed but no pv_ops > >>kernel is available. With proposed change such setup becomes > >>needlessly unbootable. > >Correct. That is the unfortunate part. But I am not sure how different > >that is from somebody configuring the kernel and forgetting to compile > >in a SATA controller. > Xen may be installed inadvertently by package manager as pulled by > some dpendency. So you may trigger it without touching kernel or > ever intending to run xen. > >If a person does build their customized kernel they should surely know > >what they would like or not? > > > They may not want to boot xen but end up with entries for it. Of course. But that begs the other question - if they are making their own kernel and a small size distro - they would surely also eliminate any other packages they don't need? But then the package manager might pull it. How different is this if a package manager pulled in say 'memtes= t' and they have no interest in using it? I am not sure how to go forward with this. The Linux upstream is going to eliminate those two CONFIG_XEN_* at some point. They are going to be more of a 'hardware backend' and 'frontend' type options. Linus thinks that parsing the /boot/config-* is a bug and no user-space should depend on it changing - and there is no 'you shall not break userspace' rule to this. Thoughts?