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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
