FUJITA Tomonori wrote:
On Thu, 18 Mar 2010 16:02:52 -0500
Mike Christie <micha...@cs.wisc.edu> wrote:
On 03/18/2010 08:58 AM, FUJITA Tomonori wrote:
- You invent your hardware specific data structure for the simplest
operation such as setting IP address.
I think this is what Jay is not trying to do. I think the patch has some
extra code like the ISCSI_BSG_HST_VENDOR parts that makes it confusing -
it got me too. The ISCSI_BSG_HST_VENDOR code in be2iscsi looks like it
is basically disabled (should remove for a formal patch when he sends
for merging).
It looks like there is a common struct iscsi_bsg_common_format that is
getting passed around, and then in be2iscsi the driver is using that
info to make a be2iscsi specific command. So scsi_transport_iscsi /
ISCSI_SET_IP_ADDR / iscsi_bsg_common_format gets translated by b2iscsi
to b2iscsi / OPCODE_COMMON_ISCSI_NTWK_MODIFY_IP_ADDR / be_modify_ip_addr.
Yeah, seems you are right. But looks like this patchset also adds the
vendor specific message support (ISCSI_BSG_HST_VENDOR)?
I still want to know why vendors can't do this via the existing
netlink interface. open-iscsi uses the netlink interface for some pdu
so I guess that having a different channel for management might be a
good idea.
Separate this request into two needs:
The first need is for the iscsi driver to have some kind of entry point to
kick off a vendor specific thing - primarily diagnostics and internal f/w and
flash mgmt items. Here, using the same mechanism that we had on the FC side,
which also supports dma payloads, made a lot of sense. I like and prefer the
symmetry.
The second need is for "common iscsi link/stack mgmt". All vendors would be
expected to implement the same items the same way - thus the formalization of
the api in the transport. It also makes sense that all use of these common
interfaces comes via the open-iscsi mgmt utilities. Given the data set, it
could be done by netlink or bsg. I gave some pros/cons on the interfaces in
(http://marc.info/?l=linux-scsi&m=124811693510903&w=2). In my mind, the main
reason these settings ended up in bsg vs netlink is - the functionality is
typically migrating from a vendor-specific ioctl set, which maps rather easily
to the bsg model. Not that netlink is that more difficult (although to NLA_ or
not may confuse some of the contributors). And, if you already had the bsg
infrastructure for the first need, you had to add very little to support it.
Thus, the main reason they are together is one of expediency. The first had to
be done, so it was very easy to use the same methodology for the second.
-- james s
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
