On Wed, Sep 04, 2013 at 04:47:27PM -0700, Robert Love wrote: > fnic doesn't use any of the create/destroy/enable/disable interfaces > either from the (legacy) module paramaters or the (new) fcoe_sysfs > interfaces. When fcoe_sysfs was introduced fnic wasn't changed since > it wasn't using the interfaces. libfcoe incorrectly assumed that that > all of its users were using fcoe_sysfs and when adding and deleting > FCFs would assume the existance of a fcoe_ctlr_device. fnic was not > allocating this structure because it doesn't care about the standard > user interfaces (fnic starts on link only). If/When libfcoe tried to use > the fcoe_ctlr_device's lock for the first time a NULL pointer exception > would be triggered. > > Since fnic doesn't care about sysfs or user interfaces, the solution > is to drop libfcoe's assumption that all drivers are using fcoe_sysfs. > > This patch accomplishes this by changing some of the structure > relationships. > > We need a way to determine when a LLD is using fcoe_sysfs or not and > we can do that by checking for the existance of the fcoe_ctlr_device. > Prior to this patch, it was assumed that the fcoe_ctlr structure was > allocated with the fcoe_ctlr_device and immediately followed it in > memory. To reach the fcoe_ctlr_device we would simply go back in memory > from the fcoe_ctlr to get the fcoe_ctlr_device. > > Since fnic doesn't allocate the fcoe_ctlr_device, we cannot keep that > assumption. This patch adds a pointer from the fcoe_ctlr to the > fcoe_ctlr_device. For bnx2fc and fcoe we will continue to allocate the > two structures together, but then we'll set the ctlr->cdev pointer > to point at the fcoe_ctlr_device. fnic will not change and will continue > to allocate the fcoe_ctlr itself, and ctlr->cdev will remain NULL. > > When libfcoe adds fcoe_fcf's to the fcoe_ctlr it will check if ctlr->cdev > is set and only if so will it continue to interact with fcoe_sysfs. > > Cc: Hiral Patel <[email protected]> > Signed-off-by: Robert Love <[email protected]> Acked-by: Neil Horman <[email protected]>
_______________________________________________ fcoe-devel mailing list [email protected] http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
