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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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.