On Tue, Dec 25, 2012 at 12:39 PM, Dave Quigley <dpquigl@xxxxxxxxxxxxxxx> wrote: > The notes below summarize what we decided during out last meeting. It also > has our next meeting date. There are some more issues that need to be fixes > > > Shooting for merge window 3.9. > > List of things to do: > > Add warning fixup patch into tree (Dave Q) > Patch to cleanup comment for dentry_init_security (Dave Q) > Patch to cleanup comment to reflect that xattrs aren’t being used in the > protocol (ismaclabel lsm hook) (Dave Q) > > Patch to remove export option (SteveD) > Patch to fix ifdefs in client (SteveD) > Patch to fix ifdefs in server (SteveD) > Patch to remove bugons (Dave) > > Rodel: > > Work on making our attribute encoding/decoding work more like > encode/decode_fsinfo. This means removing the extend fattr to use 3rd word > patch and instead placing the information inside an op specific struct. > Work on Attribute change notification: > Smaller patches if possible (client, server, support, etc...) > > Leaving RPCSECGSSv3 for now. > > January 10th next Meeting. > > Dave > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, I would like to make sure that I understand Trond's feedback on the current LNFS implementation. 1. Do we need to remove the "decode_attr_security_label" function from "decode_getfattr_attrs" and have our own operation to exchange security labels instead of piggy-backing labeled NFS request on setting/getting file attributes? 2. Do we need to remove the FATTR4_WORD2_SECURITY_LABEL from the nfs4_fattr_bitmap and exchange this information separately on a new function, say decode/encode_security_label? Please comment if this is in-line with everyone's line of thought regarding the suggested change: "Work on making our attribute encoding/decoding work more like encode/decode_fsinfo. This means removing the extend fattr to use 3rd word patch and instead placing the information inside an op specific struct." Thank you very much! Kind Regards, Rodel -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
