Re: [linux-kernel] Re: [PATCH] x86: use explicit timing delay forpit accesses in kernel and pcspkr driver

[David P. Reed]

Actually, disparaging things as "one idiotic system" doesn't seem like a 
long-term thoughtful process - it's not even accurate.  There are more 
such systems that are running code today than the total number of 486 
systems ever manufactured.  The production rate is $1M/month.

a) ENE chips are "documented" to receive port 80, and also it is the 
case that modern chipsets will happily diagnose writes to non-existent 
ports as MCE's.   Using side effects that depend on non-existent ports 
just creates a brittle failure mode down the road.  And it's not just 
post ACPI "initialization".   The pcspkr use of port 80 caused solid 
freezes if you typed "tab" to complete a command line and there were 
more than one choice, leading to beeps.

b) sad to say, Linux is not what hardware vendors use as the system that 
their BIOSes MUST work with.  That's Windows, and Windows, whether we 
like it or not does not require hardware vendors to stay away from port 80.

IMHO, calling something "idiotic" is hardly evidence-based decision 
making.   Maybe you love to hate Microsoft, but until Intel writes an 
architecture standard that says explicitly that a "standard PC" must not 
use port 80 for any peripheral, the port 80 thing is folklore, and one 
that is solely Linux-defined.

Rene Herman wrote:
> On 20-02-08 18:05, H. Peter Anvin wrote:
>  
> > Rene Herman wrote:
> > > _Something_ like this would seem to be the only remaining option. It 
> > > seems fairly unuseful to #ifdef around that switch statement for 
> > > kernels without support for the earlier families, but if you insist...
> >
> > "Only remaining option" other than the one we've had all along.  Even 
> > on the one idiotic set of systems which break, it only breaks 
> > post-ACPI intialization, IIRC.
>
> Linus vetoed the DMI switch.
>
> Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/