On Wed, 26 Dec 2012, David Woodhouse 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.
> 

I do quite a bit of automated config and boot tests to try out 
combinations that others may not have tested when developing their code; 
staging branches such as in tip are interesting to try because they 
haven't yet reached Linus and it's helpful to catch breakages before it 
reaches mainline.

> 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!
> 

Umm, you're saying that is legitimate for "make randconfig" done on a 
32-bit machine to generate 64-bit configurations?  The resulting kernel 
cannot be booted.  In the past, "make randconfig" would always generate a 
kernel that _should_ boot on that machine unless there was an underlying 
bug that should be fixed.

> > > Please could you provide the .config file?
> 
> > Attached.
> 
> Didn't seem to be.
> 

Now it is, sorry.

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

I'm stupid for saying that you've changed the behavior of "make 
randconfig" with no ARCH= workaround so that it may result in an 
unbootable kernel on i386?  From the changelog of this commit, it looks 
like you're the idiot who can't remember he's building a 32-bit kernel on 
a 64-bit machine and is throwing a hissy fit because YOU forgot to put 
ARCH=i386.  But now you're pushing that obligation, which is a change from 
the previous behavior for years, on everyone else to workaround?