On Mon 10 Sep 2012 05:05:20 PM PDT, Bhanu Prakash Gollapudi wrote: > On 9/10/2012 3:59 PM, Robert Love wrote: >> The following series implements a move from using module parameters >> as control interfaces to /sys/bus/fcoe based interfaces. A sysfs >> infrastructure >> was added to the kernel a few cycles ago, this series builds on that >> work. >> >> It moves the create, vn2vn_create, destroy, enable and disable >> interfaces >> from /sys/module/libfcoe/parameters/ to various places under >> /sys/bus/fcoe/. >> These interfaces simply are not module configurations- they are control >> interfaces. >> >> A second goal of this series is to change the initialization sequence >> for >> a FCoE device. The result of this series is that interfaces created >> using >> libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the >> following >> starting steps- >> >> 1) Create/alloc the port >> - Allocate kernel memory and create per-instance sysfs devices >> - No discovery or login >> >> 2) Configure the port >> - Change mode, set ddp_min, etc... >> >> 3) Start the port >> - Begins discovery and/or login (depending on mode) >> >> 4) Destroy the port >> - Logout and free all memory > > Robert, Can you please let me now what is the motivation for this > change and what problem are we solving with this approach? Is this > primarily to allow user to set the mode? >
The main problem is that our control interfaces shouldn't be module parameters. I think of module parameters as things that globally alter the module. I also think that moving to a create/configure/start model gives us more flexibility going forward. We don't have too many FC/FCoE knobs to tune right now, but if we wanted to add more we don't have a good way to do it without starting the whole discovery/login process and then making changes during the discovery/login. I think the module parameter problem is the justification, but I'm trying to be comprehensive in coming up with a flexible interface that will allow us to evolve as well. > I'm concerned that we will be breaking user space compatibility with > this change, as there should be a corresponding fcoemon/fipvlan change > along with this, and existing utilities will not work. Also the way > we start fcoe will be completely different and the user may need to do > the scripting changes, if any. See the last statement from my initial posting (it's below). I have patches to modify fcoemon to use these new interfaces. I'd be happy to share them, I just didn't want to spam this broad of a audience. > > Thanks, > Bhanu > >> >> I'm looking for feedback on using sysfs files as control interfaces that >> the user (application) would write interface names to. I modeled this >> series off of the bonding sysfs interface, but it was suggested to me >> that >> it might not be a good example. I belive bonding uses two values >> per-file >> a '+' or a '-" to add or delete and then the ifname apended. I am simply >> writing the ifname to the ctlr_create or ctlr_destroy. >> >> Series compiled and tested against v3.5. libfcoe.ko compile warning >> fixed >> upstream after v3.5, anyone who compiles this can ignore section >> mismatch >> warning. Also note that a modified fcoemon is needed to use the fcoe >> system >> service against this kernel modification. I'd be happy to provide that >> fcoemon code on request. _______________________________________________ devel mailing list devel@open-fcoe.org https://lists.open-fcoe.org/mailman/listinfo/devel
