[lkml]   [2011]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'
On Mon, 2011-05-30 at 21:44 -0400, Ted Ts'o wrote:
> On some architectures, I suspect there will be a dozen or more CONFIG
> that have to be a certain way in order for the machine to boot. Are
> you really going to want to put them all on the command line?

No. This is just a convenience for setting/clearing a few options
(although "make `cat my-config-overrides` oldconfig" would also work if
you have a bunch of them, I suppose.)

Remember, we're having this discussion because Ingo needs a command-line
method to override *just* CONFIG_64BIT. Nothing more. That's all that's
really holding us back from finally completing the i386/x86_64 -> x86

> I suppose the question is whether people are using randconfig for
> simple compile testing, or just for something that they actually try
> to boot, either on real hardware or on a KVM system. I was under the
> impression Ingo and others actually tried to boot their randconfig
> kernels, correct?

I *sincerely* hope that isn't the reason for this requirement. If they
*are* actually booting these kernels, then they'll need more than just
one setting to be hard-coded, as you correctly observe.

That would mean that they must already be using KCONFIG_ALLCONFIG, or an
'all.config' file which overrides the settings they need for their
storage hardware, for CGROUPS to match their userspace if they have
systemd, etc.

And that, in turn, would mean that all this whining about needing an
easier way to set CONFIG_64BIT is *pure* nonsense, because they could
have just added it to their existing list.

So no, allowing CONFIG_FOO= on the make command line was not intended as
a way to set options in bulk. We have *other* ways of doing that, which
do take them from a file.


 \ /
  Last update: 2011-05-31 10:39    [W:0.650 / U:0.344 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site