Linus Torvalds wrote:
On Sat, 22 Dec 2007, Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik <[email protected]> wrote:
Yuck. And, Linus is just being silly. Wait a year then turn on
MMCONFIG :) It took PCI MSI a while to mature, but is finally
getting there.
That _really_ doesn't work.
Old machines don't go away. We can't just say "wait a year and turn on
MMCONFIG", because all the broken machines WILL STILL EXIST.
You are reinforcing my point :)
The exact same thing can be said for PCI MSI machines that are broken.
Outside of Intel machines, early PCI MSI life was yucky and broken.
Time passed, we got a handle on the problem set, we quirked that
problematic set of systems, and life moved on.
And these days, we are benefitting from that -- most new hardware is
MSI-capable if not MSIX-capable, and we are turning that on.
Some day in the future MSI-only (no INTX) hardware will ship in volume,
and we will already be adequately prepared for that day.
But here the two items diverge: PCI MSI _can_ be an _option_ for most
hardware, hence pci_enable_msi(). But the same cannot be said for
MMCONFIG, for reasons outlined below...
Do you hate the name or the concept? I'm certainly open for a better name....
Just make it so. The name is fine, the concept is unavoidable. The people
who complain are whiners that haven't ever had to deal with the fact that
there are broken machines around.
For example, right now Jeff never sees the problem, because when MMCONFIG
doesn't work, it's never his problem - nothing in the machine works. But
if he has to add a "pci_enable_mmconfig()" to the drivers he maintains, he
sees it as a _new_ problem, so he obviously thinks it's stupid: he was
never impacted by the issues it fixed!
I forcibly turn on mmconfig on all my machines, and monitor lkml, to
make sure I'm aware of the extent of the problem -- and the extent of
peoples' exaggeration of this problem.
So it's natural for Jeff to not like it, but that doesn't make Jeff right
in this case. It just means that Jeff never had to worry about it before,
because as long as MMCONFIG wasn't per-driver, the problems it caused were
never *his* problems. But that doesn't make them less of a problem.
Doing it at the driver level fundamentally doesn't work:
Regardless of whether a driver is loaded or not, you may NEED to see
extended capabilities. The system may NEED to see those capabilities
just to parse them for sane operation.
And pciutils should be able to see all of config space, not just the
Linus-sanitized portion of it. This will make debugging more difficult,
for example, because "lspci -vvvxxx" will not be giving me the full
"before" and "after" snapshots I need from users, to see if anything
changes based on <some hardware poking during debugging>.
I know when you look you see all sorts of brokenness. But you and I
both know that will pass, with time. If its buggy, turn it off. If
not, turn it on. All these hardware makers are paying attention and
fixing errata; evidence of forward progress in that regard has already
appeared even.
Finally, this introduces a new per-device model for PCI config space
accesses, something we have NEVER done before. PCI config space should
always be all or none. If MMCONFIG is fucked, just turn it off completely.
Having to deal with NEW issues brought on by this NEW per-device config
space access model is stupid-by-design. Always-off is better than
changing the access model from global to per-device.
It is even MORE unlikely that hardware makers test the "mmconfig over
here, type1 over there" mixed accesses. Linux should not go down that road.
Always-off is better than mixed access models.
Jeff
--
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]
