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

On 9/10/2012 6:41 PM, Love, Robert W wrote:

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

quoted

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.

quoted

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 Robert for the explanation. Appreciate if you could share the 
fcoeutils patches also.