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 -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
