[cgl_discussion] PoC 6/2/5/03 Meeting Minutes

Steven Dake 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
>>functionality.
>>    
>>
>
>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 
disk (disciminator)

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:

1)

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.

2)

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 
>types. 
>
>  
>
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.

>	-pat
>
>
>
>  
>




More information about the cgl_discussion mailing list