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.
> 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.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
