[ Re why "physical" device IDs _should_ have a critical role in sysadmin ]
> I would have to agree that "stable" is critical to not driving people
> crazy. In the case of AIX, once a device is enumerated, it will retain
> the same name across reboots. Enough information is kept about each
> device to determine if it has already been enumerated (i.e. same I/O
> port address for serial devices, MAC address for ethernet cards, etc),
> or if it is a new device and should get a new name.
I caught those refs to how AIX does this ... sounds worth learning from.
Does it handle USB "port addresses" (which bus and hub)?
> > Given hotplugging, I think the best solution to such issues
> > does involve exposing topological IDs such as PCI slot names.
> > (What IDs the different applications use is a different issue.)
>
> I disagree here. In many cases you only have a very limited number of
> devices of each type (or only 1), so you don't want to be bogged down
> with physical device naming.
I'm not clear what you were disagreeing with. Though I think you've
hit on an important stumbling block: folk working with only one instance
of a given device type tend to come at this problem from a differerent
perspective. A workable naming policy needs to not make such setups
become painful; they're the "start points" most systems will grow from.
> If you have lots of a given type of device
> (e.g. disks), you _also_ don't want to be bogged down with physical
> device naming, because it will NOT be consistent across different physical
> access methods. In both cases, you want a generic name PLUS a way to
> find out the physical characteristics (attributes) of the device to do
> INITIAL configuration. If the device keeps a constant name across
> reboots, you don't care how it is accessed after the first configuration.
Sounds like you're actually agreeing with me that the ID used by
applications ("generic name") isn't necessarily the physical/topological ID
used to establish and maintain a stable non-"crazy" naming setup.
- Dave
-
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/
This archive was generated by hypermail 2b29 : Tue May 15 2001 - 21:00:46 EST