lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A01BF6A.90707@cs.wisc.edu>
Date:	Wed, 06 May 2009 11:48:42 -0500
From:	Mike Christie <michaelc@...wisc.edu>
To:	open-iscsi@...glegroups.com
CC:	davem@...emloft.net, James.Bottomley@...senPartnership.com,
	netdev@...r.kernel.org, linux-scsi@...r.kernel.org,
	Karen Xie <kxie@...lsio.com>,
	Jayamohan Kalickal <jayamohank@...verengines.com>
Subject: Re: [PATCH 4/4] bnx2i: Add bnx2i iSCSI driver.


> +
> +/**
> + * 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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ