On Wed, 2012-12-26 at 02:44 -0800, David Rientjes wrote:
> I'm sure it's a 32-bit issue, nothing has changed recently in auto-latest 
> related to these subsystems and I'm sure it's just because my randconfig 
> builds were exposed to this combination solely because of this patch.

Hm, that's an unexpected benefit of this patch. I didn't think it would
noticeably improve 'make randconfig' coverage of configs without
CONFIG_64BIT, because I thought enough people were doing such tests
already. But evidently I was wrong.

We introduced 'make randconfig' as a tool to generate meaningless
configs just to test various permutations — to ensure that we got our
dependencies right both in Kconfig and the code itself. It was
artificially limiting its test coverage and thus we were failing to
discover real bugs. Now I've fixed that problem, and 'make randconfig'
is actually random and is thus doing its job even better than before.
Yay!

> > Please could you provide the .config file?

> Attached.

Didn't seem to be.

> > >  When I do "make randconfig" and uname -m is x86_64, I expect 
> > > CONFIG_64BIT to always be set.  This commit makes this random… 
> > 
> > We've had this bizarre "I don't really want randconfig to be random"
> > conversation before.
> 
> If it were truly random then it would be generating sparc configs, hppa 
> configs, etc.  Randconfig has always generated random configurations for 
> the underlying architecture (just like you respect the architecture with 
> defconfig with your patch),

Yes, but the underlying architecture is "x86". Just like the
architecture is "powerpc", not "ppc" or "ppc64". CONFIG_64BIT is just
another config option. And AFAICT this is also true for ARCH=sparc,
ARCH=parisc, ARCH=s390, ARCH=mips and ARCH=tile. We just hadn't
completed the merge of arch/i386 and arch/x86_64 into arch/x86 yet, so
it was inconsistent.

The architecture is *not* "i486", "i686 with PAT", "i686 with cmov",
"x86_64 with 3DNow", "x86_64 with AHCI and ext4", or anything else Aunt
Tillie-ish which actually stands a chance of booting on your current
hardware. If you want to fix the values of certain config options, we
*have* mechanisms to do that.

>  the fact that it's been unified into a single 
> x86 architecture changes the behavior of plain old "make randconfig".  I 
> certainly understand how to override that with ARCH=x86_64.  However, the 
> reverse can also be said: make the same adjustment for randconfig that you 
> made for defconfig so the old behavior is maintained and allow users on 
> x86_64 to do "make ARCH=i386 randconfig" for 32-bit builds.

You can already do 'make ARCH=i386 randconfig' for 32-bit builds. You
always could. Or, as less of a special-case hack, you could use other
methods to override *any* config option, rather than just CONFIG_64BIT.

I just don't buy this "OMG you made randconfig actually random" crap.
It's a stupid thing to complain about. Making some effort to pick
i386_defconfig or x86_64_defconfig according to the build host, we can
tolerate. But randconfig is *supposed* to be random. Get over it.

-- 
dwmw2