[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110530113036.GA22324@elte.hu>
Date: Mon, 30 May 2011 13:30:36 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Theodore Tso <tytso@....EDU>
Cc: David Woodhouse <dwmw2@...radead.org>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'
* Theodore Tso <tytso@....EDU> wrote:
>
> On May 30, 2011, at 6:58 AM, Ingo Molnar wrote:
>
> >
> > * Theodore Tso <tytso@....EDU> wrote:
> >
> >> I'd think that "make ARCH=x86_64 oldconfig"
> >>
> >> ... where the old configuration contained CONFIG_X86_32
> >> should trigger a warning, if not an outright error that
> >> stops the build....
> >
> > That would be a rather sad regression for me: i use that command
> > regularly to transform .configs that came in bugreports into a config
> > suitable for a testbox that has a different bitness userspace
> > installed.
>
> OK, so to clarify, what you want is for ARCH=xxx to always override
> whatever is in .config? [...]
If 'xxx' clearly signals both architecture and bitness then it should
override both the architecture and the bitness of the .config -
that's both common-sense and currently implemented (and relied on)
behavior.
'ARCH=x86 oldconfig' should maintain bitness in the .config like it
does today, because the 'xxx' only specifies the architecture.
[ Btw., 'override the architecture' usecase is not just theoretical:
i sometimes use this form to convert existing .config's *between*
architectures, not just from 32-bit to 64-bit. So if i get an ARM
bugreport that gives me the appearance of a core kernel bug i will
often start by converting that to an x86 .config via 'make
ARCH=x86_64 oldconfig'. ]
> Are we all on the same page here? [...]
I think this thread makes it rather clear that David and me are not
on the same page. Not sure about you :)
> [...] I thought David was arguing that what was in .config should
> always be more important, since he regards "ARCH=xxxx" as "legacy".
Well i (and current behavior) argue that what the user types actually
has a meaning and a purpose and provides an override to other
environmental data.
> Or maybe I'm missing something here.... since people seem to be
> slinging around examples what should or should not work, as opposed
> to simply saying, "ARCH=xxx" must always override all else, even in
> cases like "oldconfig", "randconfig", etc. Is that what the patch
> is going to do?
I said it from mail #1 on that "ARCH=xxx" must override the .config
[except in cases like ARCH=x86 where 'xxx' does not imply bitness]
and must modify/filter other typed arguments
(randconfig/allnoconfig/allyesconfig, etc.) in an intuitive and
common-sense fashion.
> All this talk of how it's OK for randconfig to give you i386 50% of
> the time even when ARCH=x86_64 is specified is confusing me? Maybe
> that was just intended to be sarcasm?
That was the original regression i reported to David. So yes, i do
argue, and argued from day 1 on (which was 2 years ago) that
'ARCH=i386' and 'ARCH=x86_64' should override secondary sources of
environment.
It's just that David has not accepted my reasoning and has given a
changelog that describes the topic in a rather one-sided fashion.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists