Bug#500336: patch for grub detection

[Ian Campbell]

On Thu, 2008-10-30 at 18:50 +0100, Raphael Hertzog wrote:
> tag 500336 + patch
> thanks
> 
> On Thu, 30 Oct 2008, Ian Campbell wrote:
> > > What's the reasoning behind this loop ? All the suitable kernels are already selected
> > > by the first loot that matches CONFIG_XEN + CONFIG_XEN_PRIVILEGED_GUEST.
> > > 
> > > Can't we simply drop this loop and be done with it ? What do I miss ?
> > 
> > Current paravirt ops kernels cannot be booted as a dom0 but future ones
> > will be. Currently there is no way to tell them apart, there may or may
> > not be a variable similar to CONFIG_XEN_PRIVILEGED_GUEST for those
> > kernels when dom0 support goes upstream. However we have no way of
> > knowing what will happen here.
> 
> Why are we trying to guess the future here ? We want something working for
> lenny now and we'll fix that for squeeze when it has been merged upstream.

At the time of the original patch the dom0 support seemed quite
imminent. As it currently stands patches exist but have missed the
2.6.28 merge window so it is likely to be 2.6.29 before they are
available (i.e. they are still "quite imminent" ;-) ).

However you are right we shouldn't worry about it for getting Lenny out
and I think the right thing to do is for me to ask upstream to use the
CONFIG_XEN_PRIVILEGED_GUEST symbol when they add this support.

> > (I may have been mistakenly thought we were discussing that a "native
> > style" entry was being created for the -xen-686 kernel (in addition to
> > one which specified a hypervisor).)
> 
> That is also the case (since we don't drop anything out of
> sortedKernel) but it's not what this bug is reporting. Furthermore entries
> for the hypervisor tend to be first and thus any bad first entry is worse
> than any bad entry that appears later in the list.
> 
> > > All the kernels are still listed individually but that category of kernel is no
> > > more combined with the hypervisor if it's available.
> > > 
> > > We at least reduce the number of bad combinations without dropping any good
> > > combination if I trust the table given in
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500336#25
> > 
> > But this table *does* drop a good combination, which is a CONFIG_XEN +
> > no CONFIG_PARAVIRT when used inside a domU.
> 
> The table shows the CONFIG combinations in all official Debian kernels
> that we care about, it doesn't drop anything. Thomas's patch drop those
> combinations from sortedKernel however.

The table showed "CONFIG_XEN + no CONFIG_PARAVIRT -> removed from kernel
list" which is exactly what Thomas' patch implemented. It was that
dropping from sortedKernel was what I objected to since it broke domU.

> I propose to not use Thomas patch but to remove the code that tries to
> deal with future kernel that do not exist yet and to be done with that
> bug.
> 
> Please find the patch attached. It works here at least.

I'm happy with it too since it works in domU (no change).

For future paravirt ops dom0 kernels I should try and convince them to
reintroduce the CONFIG_XEN_PRIVILEGED_GUEST symbol which will make the
patches update-grub "just work" (I tested it by hacking /boot/config)

> (Note: it looks like that grub-pc's update-grub doesn't deal at all with Xen
> yet…)

A deliberate upstream policy I believe, according to one of Robert's
previous mails to this bug.

Ian.
-- 
Ian Campbell

#if _FP_W_TYPE_SIZE < 64
#error "Only stud muffins allowed, schmuck."
#endif
		-- linux/arch/sparc64/quad.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20081031/fcdc2207/attachment.pgp