From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V2nHp-0003ri-Ra for mharc-grub-devel@gnu.org; Fri, 26 Jul 2013 15:02:45 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2nHn-0003rN-Nm for grub-devel@gnu.org; Fri, 26 Jul 2013 15:02:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2nHm-00056X-B8 for grub-devel@gnu.org; Fri, 26 Jul 2013 15:02:43 -0400 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:59274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2nHm-00056K-64 for grub-devel@gnu.org; Fri, 26 Jul 2013 15:02:42 -0400 Received: by mail-we0-f170.google.com with SMTP id w60so2242457wes.29 for ; Fri, 26 Jul 2013 12:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uehnC8UrEZ+mbAf9H2V9PB/qsqbjudTue+MMbenbNTg=; b=Oo75mUMv+HiMYt2uCUzkPh5Q11T9vwA5Op96GEFcLM7Oe0+ngb5FRJu9w5WK9z3W0Q myhQSftvGOojy+WzOeoDXsJHBeSp/8cT5BDouT7VBPL9RMLicMRgrlXpZikbALAOXAzu SZ6FHo0DRvqYoU+FcJql6CD31BhWaKOKgmSaJFXuOEGn+3g4rFWwLDsIuB/BOUhydHmy wTPguFJVzGdWx2lh9djiTloyialBuATF0edHoavcFK36LwWPGm5OIxEb5wDdGL1Jaq9L KvEs29gsmY6QQjeL08cMgF83Cixiblk5aQ9JoinzQwiv6GpGXtUvF5XTe/LHVTz3K076 iUhg== X-Received: by 10.180.11.6 with SMTP id m6mr2863728wib.0.1374865361421; Fri, 26 Jul 2013 12:02:41 -0700 (PDT) Received: from [192.168.1.113] (31-249.1-85.cust.bluewin.ch. [85.1.249.31]) by mx.google.com with ESMTPSA id r8sm6656914wiz.5.2013.07.26.12.02.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jul 2013 12:02:40 -0700 (PDT) Message-ID: <51F2C7D0.2050500@gmail.com> Date: Fri, 26 Jul 2013 21:02:40 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: konrad wilk Subject: Re: [PATCH] remove dependency on /boot/config-* in grub.d/20_linux_xen References: <20130715180006.GA2433@phenom.dumpdata.com> <51F19775.5060305@gmail.com> <51F2C4F7.30206@oracle.com> In-Reply-To: <51F2C4F7.30206@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::22a 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: Fri, 26 Jul 2013 19:02:45 -0000 On 26.07.2013 20:50, konrad wilk wrote: > > On 7/25/2013 5:24 PM, Vladimir 'φ-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 being >> broken unless a good facility for your needs is supplied. In this case >> 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 provided. > 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 probably > 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_Management#Start_Of_Day > pv_ops kernel is not ELF. It's bzImage. This article doesn't apply to bzImage. > >>> The 20_linux_xen does that however it should not do it. In all fairness >>> 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 or >> 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 linux >> 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.