On May 29, 2012, at 11:43 AM, Myklebust, Trond wrote: > On Tue, 2012-05-29 at 15:05 +0000, Adamson, Dros wrote: >> On May 25, 2012, at 6:03 PM, Trond Myklebust wrote: >> >>> For backward compatibility with nfs-utils. >> >> Can you expand on that a bit? I put them where they are because they are in order of operation id (bind_conn_to_session = 41, exchange_id = 42). > > nfs4_procedures isn't (and really can't be) ordered by operation. It is > a set of COMPOUNDs, each of which reflects a certain functionality > rather than a specific operation. Oh I see. > >> If we really must only add to the end of the list, we really should have a comment above nfs4_procedures, etc. > > The whole nfsstat is currently problematic because we occasionally do > want to be able to add to the NFSv4.0 procedures (above the #ifdef > CONFIG_NFS_V4_1) as well as the NFSv4.1 procedures. > > Appending is usually the right thing to do, but that #ifdef makes it > problematic since if we were to append NFSv4.0 routines, then they would > move depending on whether or not we compile in NFSv4.1 or not. > > Adding in NFSv4.2 will give rise to even more 'interesting' situations > should we start protecting it with yet more #ifdefs... > > The solution may be to just accept that we cannot keep separating > NFSv4.0 and NFSv4.1 routines, and to just get rid of the #ifdefs so that > we can always append to nfs4_procedures[]. However we haven't yet done > this, and so there is no good 'official' documented policy. Maybe a comment with a note about how fragile this is and a reminder to test nfsstat? -dros
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
