On Wed, 2010-10-13 at 17:13 -0400, Benny Halevy wrote: > On 2010-10-13 16:54, Trond Myklebust wrote: > > On Wed, 2010-10-13 at 16:34 -0400, Benny Halevy wrote: > >> On 2010-10-13 14:03, Fred Isaman wrote: > >>> On Wed, Sep 29, 2010 at 7:10 AM, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote: > >>>> To initialize all values to zero, in case the server or protocol version > >>>> do no support particular attributes. > >>> > >>> Sorry for the delayed response, but... > >>> > >>> Zero is not an appropriate default for many of the values. Further, > >>> decode_fsinfo sets a default for each value, even in cases where the > >>> server or protocol version do not support particular attributes. So > >>> this patch seems to server no purpose. > >> > >> Note that nfs_probe_fsinfo is called also for nfs version 2 and 3 > >> and these don't know anything about nfsv4.1 attributes so they can't > >> cannot explicitly set them to any default value. > > > > Err... Why would we care? Under exactly what circumstances would we want > > generic code to be processing fsinfo attributes that are specific only > > to NFSv4.1? > > > > Trond > > Originally, set_pnfs_layoutdriver, was called only for nfsv4.1 > but we changed it to always be called in nfs_server_set_fsinfo() So it relies on a flag in the fsinfo structure to tell it that this is a pNFS-capable server? That's fine, but in that case, you should perhaps explicitly initialise that flag to the non-pNFS capable value in the generic code. We shouldn't need to zero out the entire structure. Cheers Trond -- 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
