Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars

From: David Miller <davem@davemloft.net>
To: hpa@zytor.com
Cc: rdreier@cisco.com, h.mitake@gmail.com, mingo@elte.hu,
	tglx@linutronix.de, rpjday@crashcourse.ca,
	linux-kernel@vger.kernel.org
Subject: Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars
Date: Tue, 21 Apr 2009 17:31:23 -0700 (PDT)	[thread overview]
Message-ID: <20090421.173123.191021055.davem@davemloft.net> (raw)
In-Reply-To: <49EE37AF.4020507@zytor.com>

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Tue, 21 Apr 2009 14:16:31 -0700

> Roland Dreier wrote:
>> To be honest I think the status quo ante was not really that bad.
> 
> That I have to vehemently disagree with.

I have to agree with Roland.

Unless you make it a compile failure, no driver author is going to
spend any amount of time trying to figure out how to deal with this
situation properly.

So in this sense, the current situation works really well.

If you make it just compile and make an arbitrary choice of whether
the top-32bits is read first or not, you're going to end up with
mysterious driver failures that only occur on some machines and the
cause of which won't be determined until after a lot of painful
digging.

This painful debugging experience is eliminated if the driver author
is told with a compile failure that there is an issue to resolve.

And that is what happens right now.