Re: [PATCH] [REPOST] SCSI and FC Transport: add netlink support for posting of transport events

[Mike Christie <michaelc@cs.wisc.edu>]

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?