On Mon, 2015-05-18 at 11:09 -0700, Andy Grover wrote:
On 05/18/2015 10:54 AM, Christoph Hellwig wrote:
> On Wed, May 13, 2015 at 12:13:32PM -0700, Andy Grover wrote:
>> Even though qla2xxx and qla2xxx_npiv are not represented hierarchically in
>> configfs (they're peers) I'm wondering if that's not actually a
mistake, and
>> preferable to present differently in targetcli. It might be clearer to show
>> it hierarchically -- create an "npivs" node:
>>
>> qla2xxx
>> o- 20:00:00:00:00:00:00:55
>> o- acls
>> o- luns
>> o- npivs
>>
>> in which "npivs/ create 5555666677778888 npiv_wwnn=1111222233334444"
>>
>> would actually jump over to the qla2xxx_npiv configfs dir and set stuff up.
>
> Or the qla2xxx_npiv configfs dir should go away in this form and
> we should just have the npivs subdirectories?
My first impression was that would be more natural. I'm trying to see if
there's any reason that the way it is now is preferable. But even if
there aren't, I don't know if we can look at a change due to backwards
compatibility concerns.
Intermixing NPIV and physical ports under a single
/sys/kernel/config/target/qla2xxx/ was originally considered, but since
it didn't allow for NPIV specific attributes per endpoint, I ended using
the current approach instead.
Also, the other approach means user-space needs to know a fabric can
have multiple WWPN types, and also that configfs dependencies
in ../target/$FABRIC/$ALL_WWPN/ need to be released in specific order
during shutdown.
The current approach still needs to know this for shutdown, but we can
simply drop ../target/qla2xxx_npiv/$NPIV_WWPN/* to release physical port
configfs dependencies ahead of ../target/qla2xxx/$PHYSICAL_WWPN/*.
But what configfs looks like is somewhat separate from how npiv
should
look to the user in targetcli, because we are able to paper over things
in rtslib (e.g. adding initiator groups where in configfs there are none)
rtslib is responsible for driving the fabric config layout, and it's own
object layout has been a general reflection of that.
It should also abstract away future changes to the underlying configfs
layout from targetcli + friends as much as possible.
--nab