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...
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).
> 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.
If we expected to have multiple iscsi/iser stacks present (vs the 1 and only
1 implementation we have for the other transports), then either that gets
built into the event message (as a stack identifier) or you could munge the
same thing into the vendor id (e.g. define a "type" that indicates s/w
assigned - and the vendor id is the stack identifier (but this method seems
hoaky)).
> Is there a null value or some special unused one we can
abuse or why do you need the vendor id value if you can look that up in
sysfs by just following the host no to the scsi host dir then going to
the pci device?
Hope above is clear.
-- james s
-
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
