lkml.org 
[lkml]   [2001]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Changes for PCI
Gérard Roudier wrote:
> The driver checks against PCI bus+dev+func in 2 situations:
>
> 1) To apply the boot order that user can set up in the controller NVRAMs.
> 2) To detect buggy double reporting of the same device by the kernel PCI
> code (this made lot of troubles at some time).

Cool. The premise of the thread was that you merely were checking for
uniqueness, not order. That changes our answer...


> The great bug is to invent useless abstractions that don't match reality.
> Such brain masturbation leads to confusion (hence subtle bugs) and
> useless software bloatage (thus _real_ resource wastage).
>
> If we want to handle _real_ PCI bus domains, we just have to add a domain
> number to identify a _real_ PCI device. Anything that wants to hide such
> reality in some opaque data looks like brain masturbation to me.

I think all of us agree on this: in 2.5, our solution is to have a
system domain number, which increases from zero each time you add sbus,
pci bus, isa bus, etc.

For 2.4, non-x86 arches first had to deal with PCI domains, so the
solution was to stick "arch-specific data" into pci_dev->sysdata, which
in some cases was the PCI domain number.

So, you have an ugly solution in drivers for 2.4 if you need to know PCI
domain for what reason, and a clean solution in 2.5.

Jeff


--
Jeff Garzik | Andre the Giant has a posse.
Building 1024 |
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:17    [W:1.222 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site