udev-110 ->111 changed behaviour for naming net-devices?
bryan at kadzban.is-a-geek.net
Thu May 24 04:20:32 PDT 2007
Jens Stroebel wrote:
> Bryan Kadzban wrote:
>> I'd like to see the results of:
>> grep -H . <stuff>
OK, so it looks like the top-level device is an Intel (0x8086) "82801
mobile PCI bridge" (0x2448); I suspect that device is a PCI->miniPCI
bridge, but I'm not quite sure. Anyway, next in line is an O2 Micro
(0x1217) Cardbus bridge (0x7135). Next is an Abocom Systems (0x13d1)
RTL8139 Cardbus NIC (0xab06).
(And it turns out that the subvendor/subdevice didn't matter in any of
these cases, but I figured it'd be better to ask and not need them than
need them and not ask. :-) )
Still surprises me a bit that Cardbus/PCMCIA are similar enough to PCI
that they don't show up as a separate type of bus -- but it does look
like path_id (with the patch) can handle this layout. Also, after
recreating most of this sysfs tree in a test directory on my machine and
running the patched path_id against it, I see that the ID that gets
printed is just "pci-0000:04:00.0" -- so it doesn't look like path_id
cares what's higher in the tree.
However, then I realized that the PCI location IDs are unique across a
machine anyway: that's why the second field is the bus number. Your
PCMCIA NIC is device 0, function 0, on bus 4 (and domain 0000): so long
as that doesn't change, it'll work fine.
(I should note that my current motherboard does some strange things with
PCI bus numbers, though. If my onboard SATA2 chip is disabled in the
BIOS, then the AGP bus is bus number 3 (PCIe takes buses 1 and 2, and
yes it has both). If the SATA2 chip is turned on, then another PCIe bus
is created at number 3, the SATA2 chip is put on that bus, and the AGP
bus moves to 4. Hopefully these laptops don't do anything similar.)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
More information about the lfs-dev