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? > >> This is because for >> software iscsi and iser we do not know the pci device that will be used. >> For software iscsi it could be a bonded device or multiple devices >> depending on tables getting updated. What would we use for the vendor id >> in this case? > > Well - in this case, it's not a vendor-specific event being generated. > It's an event by the iscsi/iser layer. This should fit the "well-known > to the iscsi/iser transport" event definition and not require a vendor id. > It is not vendor specific but it is driver specific and so we need a way to route the message to the proper userspace handler for similar reasons you may need a vendor id? For example qlogic handling may be slightly different in userspace then broadcom. So what I am saying is I thought the driver and vendor ids are similar, but vendor id may not work for iscsi_tcp/iser? - 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
