Re: PCI scan problems in 2.2.16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



   This is not a problem with two sides.  Rather, the problem is one of 
flexibility.  Donald has very patiently explained why the current system 
works as it does.  And he is right, if the PCI code simply scanned the bus 
in the other direction, there would be just as many people who suddenly 
find the system working against their expectations.

   What I think would go a long way towards helping people is a system for 
naming devices (be they net interfaces or scsi drives) based on the 
bus/slot number.  Once so named, that device should have that name for as 
long as that device is there.  This would let Dennis specify Bus 0 slot 7 
as eth0 and he wouldn't need to worry about detection order.  It also means 
that if Bus 0 Slot 2 was eth2 and the card in Bus 0 Slot 1 was removed, Bus 
0 Slot 2 would *still* be eth2 and the existing config files would still 
work.  In this way, adding a SCSI hard drive wouldn't render a system 
un-bootable.  This seems to be the way the RedHat kudzu stuff is moving, 
perhaps with a few more primitives it could just automagically take care of it.

   Even with a system like that, there will be people who find the default 
behavior incorrect (ever moved a net card to a different slot in Windows?), 
but the point is to provide the primitives needed to alter the default 
behavior.

-Michael
kujawa@cs.ucf.edu

-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux