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]

Date:	Tue, 11 Sep 2012 10:06:29 -0700
From:	Chris Leech <leech@...ox.com>
To:	Robert Love <robert.w.love@...el.com>
Cc:	netdev@...r.kernel.org, gregkh@...uxfoundation.org,
	linux-scsi@...r.kernel.org, bprakash@...adcom.com,
	devel@...n-fcoe.org
Subject: Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces

On Mon, Sep 10, 2012 at 3:59 PM, Robert Love <robert.w.love@...el.com> 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
>
> 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.

Can you give an example session that goes through the 4 steps above
and what the sysfs hierarchy looks like at each step?  I mostly get it
from the patch descriptions, but I think it would help discussion of
your proposed interfaces to see an example of them in use.

This feels a little awkward with all the special control files.  Have
you thought about something designed for creating kernel objects, like
configfs?  Similarly the separate start, enable, disable files vs.
having some sort of status attribute that can take different values.
I feel like these need to be rethought as attributes instead of
triggers.  Is there a big difference between start and enable?  Can
you achieve the split between create and start by having it come up in
a disabled state by default?

That being said, I'm glad this is being reworked.  Do you have any
other functionality in mind that this is laying the groundwork for?

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