Re: [PATCH] aic94xx: Use request_firmware() to provide SAS address if the adapter lacks one

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux