From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V3qhc-0008O0-Oz for mharc-grub-devel@gnu.org; Mon, 29 Jul 2013 12:53:44 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3qhW-0008Gp-4S for grub-devel@gnu.org; Mon, 29 Jul 2013 12:53:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3qhR-0004XL-CT for grub-devel@gnu.org; Mon, 29 Jul 2013 12:53:38 -0400 Received: from mail-we0-x22b.google.com ([2a00:1450:400c:c03::22b]:43265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3qhR-0004XE-6Q for grub-devel@gnu.org; Mon, 29 Jul 2013 12:53:33 -0400 Received: by mail-we0-f171.google.com with SMTP id q55so4248786wes.30 for ; Mon, 29 Jul 2013 09:53:32 -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=N7iu8q1k9AGWZoWsptaJfsdbVRo/DBsgdeX/0Rm5zq4=; b=d7zHP3Oi5mY22JX0NPCJ2ko2Wqen9aYTe9VInO+Oqjmm7BUgRQoUHRLiY0ye1/t4Qj WJETGbgXwQIeznwJKvWrbzaHD9sKIPfrzk034HK9ziOdq6fxfcsvi9Ztcpg9XaGz4ZCd GJGPEDkWBFczzSc/D1HAHe8NnH6TWlDjLjswijqtOimf9L1tRf5VpvGRzqKGtyVCbUrt YjCMib9vuwQKm12N6pFctJaJWw070ODzHshHpNKjIe6RxTGllmqWFmJ+eLaoWo9JetdV D9u4F4F7V4rXFoVbybSBhRBsn95sydDtGjGOBisgbhyKxFLwPFqMJaCQmBwuiZszl3eS f2Sg== X-Received: by 10.194.63.46 with SMTP id d14mr44789635wjs.81.1375116812420; Mon, 29 Jul 2013 09:53:32 -0700 (PDT) Received: from [192.168.43.150] (79-226.197-178.cust.bluewin.ch. [178.197.226.79]) by mx.google.com with ESMTPSA id nb12sm23772907wic.3.2013.07.29.09.53.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 09:53:31 -0700 (PDT) Message-ID: <51F69DBC.1060805@gmail.com> Date: Mon, 29 Jul 2013 18:52:12 +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 Rzeszutek 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> <51F2C7D0.2050500@gmail.com> <20130729145256.GH5848@phenom.dumpdata.com> In-Reply-To: <20130729145256.GH5848@phenom.dumpdata.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::22b 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 16:53:43 -0000 On 29.07.2013 16:52, Konrad Rzeszutek Wilk wrote: > On Fri, Jul 26, 2013 at 09:02:40PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> 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. > > Duh! It certainly is. Thought the bzImage is decompressed and there is some > form of ELF data in there, otherwise Xen wouldn't be able to load the > Linux kernel and parse the .Xen.note entries. > xen has special code for handling bzimage. Without documentation it's not easy to know what is expected from bzimage and what is guaranteed. >> 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 'memtest' > and they have no interest in using it? > memtest has no chances of being set as default. Think about headless and remote scenarios. Wrong default would require someone to physically go to the server which might be problematic. > > 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? > As I said, we need docs as to what we can rely on in bzimage xen image. Not just what is there right now but what is required and guaranteed to be kept.