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

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: <504ED04E.5000802@broadcom.com>
Date:	Mon, 10 Sep 2012 22:46:54 -0700
From:	"Bhanu Prakash Gollapudi" <bprakash@...adcom.com>
To:	"Love, Robert W" <robert.w.love@...el.com>
cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"devel@...n-fcoe.org" <devel@...n-fcoe.org>
Subject: 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:
>> 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 Robert for the explanation. Appreciate if you could share the 
fcoeutils patches also.



--
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