From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VvQpA-0006aQ-Q0 for mharc-grub-devel@gnu.org; Tue, 24 Dec 2013 07:11:00 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvQp1-0006a4-L7 for grub-devel@gnu.org; Tue, 24 Dec 2013 07:10:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvQor-0007si-Vg for grub-devel@gnu.org; Tue, 24 Dec 2013 07:10:51 -0500 Received: from e24smtp05.br.ibm.com ([32.104.18.26]:55995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvQor-0007s7-Jd for grub-devel@gnu.org; Tue, 24 Dec 2013 07:10:41 -0500 Received: from /spool/local by e24smtp05.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 24 Dec 2013 10:10:38 -0200 Received: from d24dlp02.br.ibm.com (9.18.248.206) by e24smtp05.br.ibm.com (10.172.0.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 24 Dec 2013 10:10:36 -0200 Received: from d24relay02.br.ibm.com (d24relay02.br.ibm.com [9.13.184.26]) by d24dlp02.br.ibm.com (Postfix) with ESMTP id E90C01DC0063 for ; Tue, 24 Dec 2013 07:10:35 -0500 (EST) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.8.31.91]) by d24relay02.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rBOCABQn51708138 for ; Tue, 24 Dec 2013 10:10:11 -0200 Received: from d24av01.br.ibm.com (localhost [127.0.0.1]) by d24av01.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rBOCAZkj027462 for ; Tue, 24 Dec 2013 10:10:35 -0200 Received: from beren.lan ([9.8.1.106]) by d24av01.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rBOCAQra027339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Dec 2013 10:10:34 -0200 Date: Tue, 24 Dec 2013 10:10:25 -0200 From: pfsmorigo@linux.vnet.ibm.com To: The development of GNU GRUB Subject: Re: Breakage from grub-mkconfig changes for grub-file Message-ID: <20131224121025.GA30153@beren.lan> References: <20131223220141.GA25169@riva.ucam.org> <52B8B772.9040007@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52B8B772.9040007@gmail.com> User-Agent: Mutt/1.5.21+155 (d3096e8796e7) (2012-12-30) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13122412-1798-0000-0000-0000011F8C74 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 32.104.18.26 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: Tue, 24 Dec 2013 12:10:59 -0000 Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 23.12.2013 23:01, Colin Watson wrote: > > ec824e0f2a399ce2ab3a2e3353d372a236595059 introduced extensive changes to > > grub-mkconfig, which among other things arranged to run all but a > > hardcoded list of grub.d scripts once for each of several platforms with > > their output enclosed in an "if" block. I do not feel that this change > > was well-thought-out, and I think it should be rethought or reverted > > before 2.02. I didn't see anything about it here in advance - did I > > miss a thread? > > > > The problems I have with it are illustrated by its effects on the Debian > > patch. I must emphasise that I don't think this is unique to the case > > of distributions with non-trivial patch sets, and that it's also likely > > to affect users who have made reasonable changes to /etc/grub.d/ locally > > (as they're entitled to do); distributions are just a useful > > early-warning system here. > > > > 1) Awkward hardcoded list; poor configurability > > > > 00_header, 30_os-prober, 40_custom, and 41_custom are run only once. > > The Debian patch set has an additional script which is not > > platform-dependent and should be run only once, namely > > 05_debian_theme, so I had to add another case here. Users will surely > > have other such files; not only do they have to know on upgrade that > > they need to take care of this, but they have no recourse that doesn't > > involve editing $prefix/bin/grub-mkconfig, which is not a file that > > should normally be edited by the system administrator; changes to that > > file will not normally persist on upgrades. > > > > This should be redesigned so that there is some way to declare in a > > grub.d script that it requires multi-platform support and should be > > run multiple times. (It *must* be this way round so that upgrades > > work properly.) > > > The idea was that platform-independent scripts were still runnable, > they'll just produce the same output N times and this list is just an > optimisations, specially to avoid running os-prober N times. > The alternative will be to have something along the lines of different > hashbang or implementing this functionality as sh functions. > > 2) Strange ad-hoc platform names > > > > The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen > > mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the > > platform names used in the GRUB build system, but yet they're exported > > across the interface to /etc/grub.d/ as GRUB_PLATFORM. This is messy > > and confusing, and it's not clear what promises we make about future > > changes here. > > > > We should rationalise this before issuing anything as part of a stable > > release, perhaps by adopting the same target_cpu/platform terminology > > used in the build system. Furthermore, if we made the namespaces > > match up then it would be fairly straightforward to only run grub.d > > scripts for platforms for which we have installed GRUB modules, which > > seems as though it would be sensible. > > > GRUB platform names don't match with the OS compatibility. On x86 other > than xen you can use the same kernel on all the platforms. On ARM, for > what is arm-uboot platform for us may require different kernels for > different hardware. > > 3) Breaks function definitions > > > > In the GRUB script language, "function" is only permitted at the top > > level. This may be an oversight since bash doesn't share this > > restriction and GRUB script generally tries to look like bash; > > nevertheless it exists today. Part of the Debian patch set causes > > 10_linux to emit a function definition, which now causes a syntax > > error. > > > > I think my preferred fix here would be to implement functions other > > than at the top level, but it seems a bit rash to try to cram that > > into 2.02. > > > Ok. > > 4) Smaller bugs > > > > Aside from the bug fixed in 77ec462a568fc9c89ef45e960bf33b5de73140fb, > > I'm pretty sure that the condition for the "x86" platform is buggy; > > shouldn't it have an extra "-a" in there? This sort of thing makes me > > worried about the level of testing these changes have had. > > > Nice catch. > > > The grub-file tool seems reasonable and useful to me, but can we just > > revert the grub-mkconfig parts of these changes until after 2.02 so that > > the effects of these interface changes can be considered more carefully? > I think it's good to move it to "next", together with --root-directory > functionality of grub-mkconfig. > Paulo Flabiano Smorigo wanted this feature badly. Unless he has striking > arguments why 2.02 needs it, I'm ok with moving this to "next". > We can move this to next. The --root-directory is not high priority and can delay it without problems. > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel