Darrick J. Wong wrote:
Though I don't see why both can't coexist cleanly -- I take it the use
case you are considering is: software recognizes no valid WWPN
available, query via request_firmware() fails, software halts
initialization (rather than fail), and awaits the admin to poke
'0x123456.. > /sys/.../fc_host/soft_port_name', causing a ping to the
driver and continuation of initialization with requested portname?
Hmm... could we use such a sysfs attribute to reassign adapter WWNs at
arbitrary times? Is that even a good idea?
As the threads on this topic has shown - allowing any kind of override
or WWN generation isn't a well-liked idea. But there are plausible
scenarios where it makes sense.
Here's one pro for setting WWNs at arbitrary times...
If the box is migrating applications (say containers) that want
different SAN connectivity, where that connectivity (view) is based
on their WWN, it would be really nice to selectively set the WWN and
not touch the SAN config. Granted, in FC, NPIV can do the same thing,
but this could be done on an adapter or configuration that can't do NPIV.
So, what's the decision - are we only allowing this for physical adapters
that don't have a name ? or are we allowing it to be more dynamic ?
My thoughts on request_firmware() vs sysfs:
via request_firmware
pro: It seems to imply a stronger level of control, as it seems more
hidden from the casual admin and/or tools. Too many random things
now peruse sysfs attributes without knowing their meaning.
Also, easier (more correct) to pass multiple elements (WWNN & WWPN)
if needed.
con: ?? when does it get used - only at initial attachment and
under failure ? If you were to make it more arbitrary, doesn't
it imply some sysfs use to poke the driver/transport to get the
new value ? and if arbitrary, how to marry that with kdump so the
initrd is up to date. Also, it's yet another mgmt interface - how many
does an admin need to know about ? Hotplug scripts to identify the
adapter and specify the proper names are more complex for the admin
than sysfs.
via sysfs:
pro: Keeps all mgmt in the sysfs area, which admins are starting to
become comfortable with. Easily supports a dynamic, change at any time
model.
con: Drives to a set-after-attachment model, and doesn't support kdump
well (requires initrd tools). Multiple elements can be a bit cumbersome
if one follows the one-value-per-attribute sysfs rules.
Must protect against random rogue sysfs tools.
Overall, I guess I like the stronger controls of request_firmware(), but dislike
using yet another mgmt interface for admins.
-- james s
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
