Robert Love wrote:
> On Mon, 2010-03-15 at 18:36 -0700, Joe Eykholt wrote:
>> Robert Love wrote:
>>> On Mon, 2010-03-08 at 11:17 -0800, Joe Eykholt wrote:
>
> <snip>
>
>>>> 3. Like 2 with simpler parsing could be as simple as:
>>>>
>>>> <nic> [<flags> [<wwpn> [<wwnn>]]]
>>>>
>>>> Where flags could be single-letter flags for various modes and options
>>>> like: f for fabric, m for vn2vn multipoint, p for vn2vn point-to-point,
>>>> etc.
>>>> This would use less code in the kernel, and maintains compatibility.
>>>>
>>> I don't find the option passing to sysfs very nice. We'd have to
>>> implement option parsing in the kernel which I can imagine would get
>>> ugly quickly if we need other options later. I'd prefer multiple sysfs
>>> files over one that takes multiple options. Multiple sysfs files could
>>> cause problems if you touch one after the enable call (assumes
>>> create/enable split). Is there any precedence here? I'm not familiar
>>> with any modules that do option parsing.
>> Of course the kernel itself does option parsing from the boot options.
>> I didn't find those routines exported, but there are file systems that
>> do option parsing on the mount syscall, and those routines are exported
>> from lib/parser.c. That seems like an OK mechanism. One example use is in
>> udf_parse_options() in fs/udf/super.c. Its also used by other modules
>> like selinux and infiniband.
>>
>> It seems like most of them use comma separated options like:
>> param=value,param=value,...
>>
>> The code to use another separator is easy, but comma has some precedence,
>> and won't appear in interface names, I think.
>>
>> We could make the first value be the interface name for compatibility,
>> and do:
>> eth0,port_name=1234567812345678,fip=ptp,fcp=[target|initiator|both]
>>
>> or something like that:
>>
>> The full set of options I can think of now are:
>>
>> port_name=<value> // set the port name to the supplied hex value
>> node_name=<value>
>> fip=[ptmp|ptp|fabric|off|auto] // FIP mode to use
>> fcp=[target|initiator|both]
>> disable // don't enable, just create?
>>
> I was thinking more about this and I don't think that these options will
> be exclusive to libfc/libfcoe/fcoe and so they should probably be under
> the fc_host/fcoe_host/whateveritbecomes since other HBA/CNAs might need
> them; I'm pretty sure you already mentioned this in your initial mail.
I think modifying scsi_transport_fc to expose some setting for FCoE can
be done cleanly. What I propose is this, under fc_host for now:
New file 'enable'
- writable if lower-level driver (LLD) provides routine for it.
- reads as 1 or 0. Write 1 to enable, 0 to disable.
- if no LLD routine, reads as 1 always.
- the existing fcoe parameter files 'enable' and 'disable' can remain
or be deprecated and eventually removed.
Files 'port_name' and 'node_name' (currently read-only).
- if LLD provides routines, they can be written when the device is disabled.
New file 'fip'
- exists only if LLD supports it (libfcoe supplies a routine).
- can be set to auto, off, FCF, or VN2VN, or (maybe eventually) P2P.
- VN2VN is better than P2P ... P2P is a restricted subset.
- Default set by LLD.
- can be written only when disabled, or possibly only until first enabled
(controlled by LLD).
In fcoe.ko, the existing module parameter file 'create' continues to
work as before, but if the interface name is preceded by a '-' character,
(or similar compatible change) we start disabled. This keeps the kernel
compatible with current user tools, but allows newer tools to create
the interface, change some settings, and then enable it.
Does this sound OK? Any relevant suggestions?
> If that becomes the case then I'm not aware of any netlink interfaces
> exposed by the FC transport, so it might not be appropriate. AFAIK under
> the FC transport the only user/kernel interface (excluding passthrough
> which builds on BSG) is to use individual files for each knob.
This isn't mutually exclusive, but I prefer to work on the /sys approach.
Thanks,
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
