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

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

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.