[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 Tue, 2011-05-31 at 14:45 +0200, Ingo Molnar wrote:
    > * David Woodhouse <> wrote:
    > > > Also, i prefer to type out the architecture due to:
    > > > | ...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'. ]
    > >
    > > So first you point out that it's automatic, and then you still specify
    > > it manually?
    > Currently it's not automatic so i prefer to type it out.

    No, you were right the first time. It *is* automatic.

    If you take an ARM config and on your x86 box you 'make oldconfig', it
    *will* be converted. There's absolutely no need to set ARCH= on the
    command line.

    > > > Could you please stop with this borderline taunting tone?
    > > >
    > > > You've been wrong so many times in this thread that i think
    > > > toning down some of your shouting in favor of a bit more
    > > > listening would be well advised ...
    > >
    > > No, Ingo. I haven't been wrong. [...]
    > Of course you've been wrong more than once - and you are now forcing
    > me to count them.
    > Lets start with your very first mail:
    > Message-ID: <>
    > "Ingo's objection that he didn't actually want 'make
    > randconfig' to give him a random config"
    > You now know that your claim was wrong, right? :)

    Absolutely not. To quote your reply:

    "...the problem with your patch was that your patch actually *broke*
    existing filtered-randconfig behavior, for example trying to get a
    64-bit randconfig:
    "make ARCH=x86_64 randconfig
    "... will today produce a 64-bit randconfig while with your old change
    applied it produced a 32-bit randconfig 50% of the time."

    In the above quote, you *are* objecting that the value of CONFIG_64BIT
    in the resulting config is *random*. You *are* objecting that it made
    'randconfig' actually random.

    We have $KCONFIG_ALLCONFIG/allrandom.conf/all.config which allow you to
    override *various* settings in 'randconfig' so that they aren't
    randomised, but you either weren't aware of that or you didn't want to
    use it for some reason. I wasn't aware of it at the time either, so
    didn't point it out to you.

    > " I still maintain that if you actually want a non-random
    > 'randconfig', perhaps because you want it to be bootable on
    > certain test machines, then you're going to need to hard-code a
    > whole lot more than *one* config option — and you'd be better
    > off coming up with a proper mechanism to do *that* instead of
    > preserving the old 'ARCH=i386' and 'ARCH=x86_64' as a dirty hack
    > to achieve it only for the CONFIG_X86_32 option. "
    > Here you clearly didn't know about KCONFIG_CONFIG, so you incorrectly
    > delegated ARCH=i386 / ARCH=x86_64 to a 'dirty hack'.

    You have done nothing to show that using ARCH=i386/ARCH=x86_64 to
    override the value of CONFIG_64BIT should not be considered a 'dirty

    I've provided a clean, generic way to set config symbols from the
    command line, and now it is just just a dirty hack but an *obsolete*
    dirty hack.

    I'm not sure how KCONFIG_CONFIG relates to that. Even if you mean
    KCONFIG_ALLCONFIG, that just means that there was *already* a clean and
    generic way to do it, so you're calling me wrong because I should
    actually have said:

    "We *already* have a proper mechanism to do that instead of preserving
    the old 'ARCH=i386' and 'ARCH=x86_64' as a dirty hack..."


    > Message-ID: <>
    > "I believe that this 'filtered randconfig' behaviour is now fairly much
    > the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'."
    > You are wrong again - it isnt, as me and others pointed it out.

    Not *so* wrong that all those other use cases couldn't be addressed in
    the same, simple patch to allow CONFIG_FOO on the 'make' command line.

    But yes, I agree that there were other ways in which people wanted to
    override CONFIG_64BIT on the command line, that I did not list.

    Some of them were even not covered by the existing KCONFIG_ALLCONFIG

    > " Other than that, we ought to finally be able to 'complete' the
    > merge of 32-bit and 64-bit support into ARCH=x86, and remove
    > the last traces of the obsolete ARCH={i386,x86_64} settings
    > completely? "
    > And you are wrong again - many people rely on it and it's useful so
    > it's not "obsolete".

    I strongly suspect that most people who set ARCH=i386 and ARCH=x86_64 on
    the command line are only doing so to work around the original bug that
    I set out to fix, where a simple 'make' would ignore your setting of
    CONFIG_64BIT in the existing .config, and override it to match the build

    The arch/i386 and arch/x86_64 directories are dead; the ARCH= settings
    to match them are obsolete — especially now that we have a cleaner way
    for people to override the setting of CONFIG_64BIT on the command line.

    > " And as I said, it's still an incomplete solution if you
    > actually want a 'filtered randconfig' to do anything *useful*.
    > "
    > Wrong again: you miss KCONFIG_CONFIG.

    I do think you mean KCONFIG_ALLCONFIG? So in this case you're saying I'm
    wrong because I should have called the ARCH=x86_64 hack an incomplete
    *and* *redundant* solution, rather than just 'incomplete'?

    > Message-ID: <>
    > " No, ARCH= is just for cross-compiling. If you're *on* an ARM or
    > MIPS box, you don't need the ARCH= bit. "
    > That's wrong again: ARCH= can be used to just extract a config
    > variant of an architecture (with no intention to cross-build - this
    > will even work without *any* crosscompilers installed),

    Now you're just being silly. Yes, I was lazy and said 'cross-compiling'
    when I could have said "cross-compiling or cross-configuring or
    cross-header-installing or cross-module-installing or cross-linking
    or ....". But the point I was making was exactly the same.

    So yes, I was slightly wrong once when I underestimated the amount of
    'valid' uses there still were for using 'ARCH=i386' or 'ARCH=x86_64' on
    the command line. But as I said, not so wrong that we couldn't satisfy
    *all* those with the same simple patch.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-05-31 15:47    [W:0.029 / U:4.228 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site