Re: [PATCH] remove dependency on /boot/config-* in grub.d/20_linux_xen

[Konrad Rzeszutek Wilk]

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.

> >
> >>>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.

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?


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?