On Sun, 30 Dec 2007, Rene Herman wrote:
>
> rene@7ixe4:~/src/port80$ su -c ./port80
> cycles: out 2400, in 2401
> rene@7ixe4:~/src/port80$ su -c ./port3cc
> cycles: out 459, in 394
>
> As stated a few dozen times by now already, port 0x80 is _decidedly_ _non_
> _random_
Oh, I agree 100% that port 80 is not random. It's very much selected on
purpose.
The reason we use port 80 is because it's commonly used as the BIOS POST
debug port, which means that it's been a reasonable "safe" port to use,
since nobody would be so crazy as to actually hook up a real device behind
that port (and since it is below 0x100, it's also part of the "motherboard
range", so you won't have any crazy plug-in devices either).
Pretty much all other ports in the low 256 bytes of IO have been used at
some point or other, because people put special motherboard devices in and
pick from the very limited list of open ports at random. So there are
ports that are not commonly used (notably 0xB0-0xBF and 0xE0-0xEF), but
they are quite often used for stuff like the magic Sony VAIO rocker-button
devices etc.
So 0x80 _is_ special. We've been able to use it for 15+ years with
basically nobody being so insane as to put an anything there.
However, I'd like to point out that the *timings* aren't special per se.
The only reason you see such slow accesses to port 80 is not because port
80 is special from a timing standpoint, but because it falls under the
heading of "no device wanted to accept the access", and it wasn't decoded
by any bridge or device. So it hits the "access timed out" case, which is
just about the slowest access you can have.
But that does't mean that other ports won't have the same timings. Also,
it doesn't mean that we really need to have exactly *those* timings.
But yes, the timeout timing is pretty convenient, because it's basically
almost universally always going to take one microsecond to time out,
regardless of speed of CPU. It's been impressively stable over the years.
But do we *need* it that stable? It probably would be perfectly fine to
pick something that gets faster with CPU's getting faster, because it's
generally only really old devices that need that delay in the first place.
In other words, the really *traditional* delay is not to do an IO port
access at all, but to just do two short unconditional jumps. That was
enough of a slowdown on the old machines, and the old machines are likely
the only machines that really care about or want the slowdown in the first
place!
In other words, what I'm trying to say is:
- yes, "port 80" is very much special
- yes, the timings on any port that is unconnected (or connected to some
interal ISA bus like the LPC often is) have been impressively stable
over the years at about 1us.
- but no, I don't think we really need those special timings. The fact
is, hardware manufacturers have been *so* careful about backwards
compatibility, that they generally made sure that the "two short jumps"
delay (which is no delay at all these days!) _also_ continued working.
I also think that the worries about PCI write posting are unnecessary. IO
port accesses (ie a regular "inb()" and "outb()" even _without_ the "_p()"
format slowdown) are already synchronous not only by the CPU but by all
chipsets. That's why that "outb" to port 0x80 takes a microsecond: because
unlike a MMIO write, it's not only synchronous all the way to the chipset,
it's even synchronous as far as the CPU core is concerned too (which is
also why all high-performance devices avoid PIO like the plague).
So even if that "port 80" access will also cause PCI postings to be
flushed, so would the actual IO access that accompanies it, so I don't
think that is a very strong argument.
With all that said: it is certainly possible that the 1us timing makes a
difference on some machine, and it is certainly *also* theoretically
possible that there is a buggy chipset that posts too much, and the port
80 access might make a difference, but it's not all that likely, and I
suspect we'd be better off handling those devices/drivers on a one-by-one
basis as we find them.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
