For the transport classes we have been providing a common interface to 
get transport specific values. For example, for all iscsi drivers we can 
get the target name in sysfs or for FC we can get the node name in a 
common place in sysfs. Or we can get transport events via the classes 
netlink APIs.

For iscsi, We are now trying to support qla4xxx and be2iscsi (iscsi 
offload cards that are a little different from what we support today 
with bnx2i and cxgb3i) management. With qla4xxx you can do:

1. Just send a binary blob with configuration values between the card 
and userspace using a binary sysfs file or netlink.


2. Extend the existing netlink and sysfs code so that the driver can get 
the rest of the values it needs in a format that makes sense for both 
drivers. With this we would add some netlink messages that are 
sent/received through the iscsi class netlink code. The new messages 
would have a bunch of iscsi or net or iscsi hba config values. Then the 
drivers would take those values or requests and do some mbox command to 
the card to get/set the config params.

My question is there a preference or rule that says we should do #2? Or 
is doing #1 ok?

In my opinion, #1 is very easy and would be the easiest route. However, 
anytime there is a format change I am relying on the vendor letting me 
know so I can update the iscsi tools. To some vendors the iscsi tools 
are secondary to their own tools, so I am not sure how much love I am 
going to get. If it is allowed though, I will not stop vendors from 
doing it. #2 is nice, because it makes it easier for any tools to manage 
any cards.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to