Mike Christie wrote: > James Smart wrote: >> Mike Christie wrote: >>> James Smart wrote: >>>> How big of a number do you need ? 48 bits ? >>>> We can up to 64bits, but I'd reserve 8bits for a "type" field. >>>> (ugh, sounds like I'm redefining naming authorities...) >>>> >>>> On a side thought - is the mac address really the right thing to >>>> use for a vendor id. Wouldn't you be extracting the vendor id from >>>> the mac address ? >>>> >>> I was looking for a persistent per hba value for some other long reason >>> that we can work around in userspace so I take back that comment. >> Ok - does that mean you want more than 24 bits for a vendor id ? >> Seems reasonable... > > No. I meant to say below I do not need it. I thought that is what you > were telling me :) Given the host no I can find the mac address or pci > vendor or device id in sysfs > >>> Are you only sending the vendor id to match some vendor specific >>> userspace code with the event? >> I'm only passing vendor id on events that are vendor specific. Thus, match >> on vendor id to decode the vendor event. All other events are "well-known" >> by the transport, so vendor id is irrelevant. For well-known events, >> host no >> should be all you need. >> >> If you need to find the vendor matched to the host no, then you follow the >> other sysfs links appropriately (and should eventually resolve this from >> the general driver framework attributes). >> >> The passing of the vendor id in the vendor messages is simply to make >> application code simpler - so it doesn't have to following all the sysfs >> links, or know the nuances of different i/o busses and their sysfs >> attributes if the vendor supports more than just pci. >> >>> Currently, for iscsi we only send the >>> host no then match the driver, host and some driver or vendor specific >>> code by using the host no and proc_name attr. >> Yep this is what I would expect - except that proc_name won't always be >> there (it's deprecated). > > Are you sure it is depreciated? I thought the proc name for proc was > depreciated but then we added it to sysfs so we could figure out which > module goes with which host or something didn't we? > I think maybe a link from the scsi host to the driver's /sys/module would be better. I will try to send something if proc_name is depreciated. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
