Re: [Xen-devel] [PATCH] xen: remove unused Kconfig parameter

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Jul 09, 2013 at 10:01:50PM +0200, Borislav Petkov wrote:
> On Tue, Jul 09, 2013 at 01:19:09PM -0400, Konrad Rzeszutek Wilk wrote:
> > My thinking is that what should be done to have some sense of history
> > is that the patch in GRUB to not rely on kernel internals should be
> > done. Then that git commit of that tree should be mentioned in this
> > kernel patch.
> 
> That's absolutely backwards and you know it. The two things - the kernel
> and grub2 - have a defined interface and it is the only way they should
> interact. Everything else is a bug.
> 
> > I wouldn't want GRUB2 to have regressions and stop generating the
> > proper menu options. That smells of userspace regressions and I am not
> > too keen to have Linus point this out to me.
> 
> You keep repeating that...
> 
> Dear Konrad, we need to talk about what a userspace regression is. And
> in that case, grepping through the kernel .config and suddenly not
> finding a certain symbol is not. That's like objdump-ing vmlinux and
> relying on something there.
> 
> The patch removing this symbol is not violating a defined interface to
> userspace. So you can't claim we're breaking anything here.

I am not clear what the boundary is. Let me get Linus's guidance on this
after the rc0 madness.
> 
> > Once that is done we can follow up on this patch and perhaps also
> > nicely convience the initial author of this patch to look at removing
> > the CONFIG_XEN_DOM0 and replacing them with the two other CONFIG
> > options that Jan and me have been discussing.
> 
> Yes, but please make sure there's a bug opened against grub2 which lets
> them know that grepping kernel configs is doomed to break sooner or
> later.

I presume that grub2 folks are as strained for resources as everybody else
- meaning they won't get to doing a patch until somebody screams.

If there is a bug I try to fix it. In this case it looks like the bug is grub2
and in the kernel. Hence the fix should be in both places. If it can be done
in parallel that would be great. Since we have some time to actually fix in
in both places why not do it? 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel