On Mon, 2013-07-15 at 10:17 -0700, Linus Torvalds wrote: > On Mon, Jul 15, 2013 at 8:40 AM, Konrad Rzeszutek Wilk > <konrad.w...@oracle.com> wrote: > > > > I am hoping you can help me draw an understanding and a line in sand > > whether: > > a) Tools should not depend on /proc/config.gz to figure out whether > > a kernel has some CONFIG_X=y feature. > > Well, /proc/config.gz is better than some crazy saved-off config file, > since it at least is guaranteed to match the kernel you're running, > but it's still a completely crazy idea. Not the least because it's not > at all guaranteed to be there, and even if it's there, we'll rename > config options without caring one whit. It's meant for "make > oldconfig" style stuff, nothing more. Any user program that depends on > it is broken by design. > > > b) If they are OK to do so, what do we do when certain CONFIG_X options > > get reworked/removed. Would they be considered regressions? Aka > > is this similar to 'you shall not break user-space'? > > Absolutely not. If you depend on any config file, you're broken by > definition. The only thing that can depend on the config file is the > kernel tree itself, and even then we happily break that at any time > (ie "make oldconfig" is meant to give an _approximation_ of the old > config, but if some config option gets renamed, the old value is > thrown away without question, and the new name is asked about). > > > Irrespective of that, do you have any ideas of how a user-space program > > (say GRUB) > > can figure out whether the configuration stanze it generates is supported by > > the kernel.
I'd like to point out that Google Chrome also makes use of CONFIG_ tests to detect support for namespaces and pid containers and stuff. > If you don't want to answer this question - since this might > > open a can of worms you prefer not to deal with - that is absolutly OK. > > I think grub should stop trying to be clever. Quite frankly, from my > own experience, grub has become too clever by half, and become harder > to use and configure as a result. Just don't do it. > > If you want to have grub Xen options for the kernel, make them grub > options. In the grub config file. And if that option isn't there, just > boot it as a native kernel. That had better work anyway, and is a hell > of a lot more flexible and stable anyway. Don't try to be clever, and > certainly don't try to parse some random config file that may or may > not even match the kernel you're booting. > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
