We can do that, in two different ways. As PCI domains are discovered,
devices or kobjects can be registered that represent their existence.
Depending on what their parent is, they can be added anywhere into the
hierarchy.
It might be good to do this anyway, since it will give us the ability to
keep a list of all PCI domains in the system, assuming that's desired. :)
> Look in /sys/bus/pci/devices/ There you have all the PCI devices
> lumped together in one place, and we obviously need the domain number
> in the name. I don't know where the 0 on the end of /sys/devices/pci0/
> comes from, but if we could, I wouldn't say no to:
>
> /sys/devices/pciDDDD/DDDD:BB:SS.F
> or
> /sys/devices/pciDDDD:BB/DDDD:BB:SS.F
> (Domain,Bus,Slot,Func)
We could do that (as well as what is described above). However, it's
important to note that this exposes a limitation of the driver model. We
have a flat name space in /sys/bus/<bus>/devices/, which is very handy,
and nearly free, since each bus maintains a list of all devices anyway.
However, since it's a flat listing, the names must be unique across all
instances of that bus.
Fine, but the names are currently taken directly from dev->bus_id, meaning
that the local directories for the devices must also be unique across the
entire bus namespace. This is certainly not true, and something that Linus
has complained about before. The names in the local directories only need
to be unique in the local namespace.
Unfortunately, the symlinks are created in the core, and the core doesn't
know about bus/device organization. A possilbe solution would be to
represent bus instances in the core, and have the symlink names created
from a concatenation of the bus name (e.g. DD:BB) and the local device ID
(SS.F). This would reduce pressure on bus_id size, and make things easier
to read..
-pat
-
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/