Michael Chan wrote:
On Wed, 2009-05-06 at 09:48 -0700, Mike Christie wrote:
+
+/**
+ * bnx2i_nl_mesg_recv -
+ * @buf: pointer to buffer containing vendor specific message
+ * @buf: buffer length
+ *
+ */
+static int bnx2i_nl_mesg_recv(struct Scsi_Host *shost, uint16_t priv_op,
+ int status, char *buf, int buflen)
+{
+ struct bnx2i_hba *hba = iscsi_host_priv(shost);
+
+ switch (priv_op) {
+ case NX2_UIO_UEVENT_NEIGH_LOOKUP:
+ default:
+ /* handle by cnic driver */
+ hba->cnic->nl_priv_msg_recv(hba->cnic, priv_op, buf, buflen);
+ break;
+ }
+
+ return buflen;
+}
I think I was wrong with one of the comments I gave you.
It seems like we have two iscsi net config models.
1. qla4xxx and Server Engines type of setup where the driver just tells
the card to use some ip or do dhcp and some other net settings and it
does all the net magic. The iscsi driver does not have to worry about
anything like the dhcp process or arp. It only passes down the setup values.
2. cxgb3i and bnx2i type of model where kernel or userspace code is
needed to execute many net operations.
- Right now, cxgb3i sort of cheated :) and only supports static IPs. It
currently uses the iscsi set param interface to do this.
- bnx2i wants to add more complicated features and is going to do them
in userspace. It us using the private messages that were added in the
previous patch.
I think cxgb3i is one day going to want to support the same features
bnx2i does. If that is right, then should we just make the NX2_UIO
events common iscsi events, and hook cxb3i in? It would not use the
iscsi set param interface at all and would work just like bnx2i. Is that
possible? What about future drivers? Are done making iscsi cards and
drivers. If so, thank goodness :) If not then maybe we want to consider
some future driver using the #2 module and possibly using this.
If cxgb3i is really only going to support static ip setup and we think
that bnx2i is going to be unique on how it sets up the network then I
NX2_UIO private events are fine. Or is this a case of we are thinking
that iscsi hardware people are creating crazy interfaces so there is no
why to predict what they are going to do so there is no point in trying
to design for them.
If there is any possibility that cxgb3i will use something similar to
bnx2i, I think we can change the message to a standard one and make the
message structure somewhat more generic. We'll probably still need a
private area in the message for hardware or vendor specific information.
Ok sounds good to me.
--
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
