Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces

On Mon 10 Sep 2012 05:05:20 PM PDT, Bhanu Prakash Gollapudi wrote:

On 9/10/2012 3:59 PM, Robert Love wrote:

quoted

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

quoted

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.