[cgl_discussion] PoC 6/2/5/03 Meeting Minutes
sdake at mvista.com
Wed Jun 25 12:08:35 PDT 2003
Patrick Mochel wrote:
>>Status of SDE
>>Project progressing. Discussion about parent needed from scsi device
>>to scsi host to pci device. parent's needed for all devices, not just
>>SCSI devices. MontaVista working on attributes for this kind of
>I'm not sure I understand this issue about parenting.
>For device naming, the physical location of a device is irrelevant,
>especially since it can change. The things you're likely to care about are
>what type of device it is (e.g. disk, mouse, etc) and what instance it
>is. IOW, you care about the class information for the device.
It is true that one level of parenting is not particularly useful. It is
desireable to know, however, that a scsi disk is connected to a
particular fibre channel adaptor, and that fibre channel adaptor has a
host IEEE ID which is unique (even if positions change). It is also
desireable to know that a cdrom is attached to a USB device instead of a
SCSI device for the execution of policy methods.
The real value of parenting is determination of the complete device
path. As an example, consider a SCSI disk behind behind a scsi PCI
device, behind a PCI bridge, behind the host PCI bridge.
By walking backwards from device to device a complete slot path address
is built. The path
from above would be:
host bridge name -> bridge (dev, func) -> SCSI HBA (dev, func) -> SCSI
The paths are absolute references and may be used to infer information
that is valuable to some.
With an absolute reference for the adapter "owning" a device it become
possible to handle important issues in system configuration for
"desktops" and hot swap situations. The key points are:
It becomes possible to have a "hardware map" for a particular system.
User space policies can then insure that eth1 is always eth1 even if it
is the only interface that comes up.
An administrator can obtain the map from a vendor or build one. Now
there is a "keep this device known as this damn it" capability. This is
really useful in some hot swap system and to desktops as well.
It becomes possible to create policies for siutations that are important
to some. However only those who care need to deal with it. One can
detect that a device has been relocated (and the policy can decide this)
or replaced (different disk, same location so the system name can remain
the same across reboots - a disk is named once and its name sticks with
it for the "life" of the system.
In a Telco setting it is also possible to test for plugging in a device
where it isn't supposed to be and notify an administrator to deal with it.
The device path is device independent and can be used with hot swap
controllers too, not just the devices that hang off of controllers. In a
system slots the wiring to the slots is fixed and now this can be used
to deal with hot plug issues - Hey! The MAC address of the ethernet
controller in slot 5 has changed; the controller must have been replaced
so the policy will keep the system name the same.
>For persistant device naming, you're also going to need some sort of
>unique identifier for the device, which should be exported via an
>attribute in the device's directory. Determining a consistent ID format is
>tricky; it must be simple and make sense across different bus and class
A consistent identifier that is atleast unique per class would be
extremely helpful, but even without this information, user components
could obtain unique identifier information based upon other attributes
for the device. As an example, the host/bus/channel/lun of a SCSI device
could be used to issue a mode page 83 read to retrieve the IEEE ID, or
an ioctl could be issued to retrieve the MAC address of a device. So it
may not be strictly necessary and would touch several mid-layer driver
components to add this sort of functionality.
More information about the cgl_discussion