linux-kernel - Re: [PATCH] Fix corruption of CONFIG_X86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 May 2011 14:45:37 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Ted Ts'o <tytso@....edu>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>,
	Randy Dunlap <rdunlap@...otime.net>
Subject: Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'


* David Woodhouse <dwmw2@...radead.org> 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.

> > 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: <1306707270.2029.377.camel@...infradead.org>

    "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? :)

   " 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'.

   Message-ID: <1306745835.2029.389.camel@...infradead.org>

    "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.

    " 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".

    " 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.

   Message-ID: <1306750004.2029.413.camel@...infradead.org>

   " 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), *and* it can 
also be used for consistency if you use mixed environments where you 
might not necessarily always be aware of exactly which box you are 
on.

etc. etc.

How many times do you need to be proven wrong before you admit having 
been at least slightly wrong, hm?

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/