On Jul. 17, 2008, 15:09 +0300, Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote: > On Wed, 2008-07-16 at 16:22 +0300, Benny Halevy wrote: >> On Jul. 16, 2008, 15:57 +0300, Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote: >>> Why do we need to handle OP_ILLEGAL in the first place? This is the >>> client; it isn't supposed to send illegal operations... >> Right, but it helps in the development process when dealing with >> a broken version of the server or the client to pass a less >> generic error (-EOPNOTSUPP) up the stack rather than -EIO. > > NFS4ERR_OP_ILLEGAL literally means "this operation isn't even listed in > the 4.0/4.1 RFC". That's out in EYOUUTTERLYINSANECLIENT territory, and > so the current mapping to EOPNOTSUPP is just wrong. FWIW, we currently map NFS4ERR_NOTSUPP to -ENOTSUPP and NFS4ERR_OP_ILLEGAL to -EOPNOTSUPP so one can distinct between the two cases, even if the latter mapping is wrong. I'm not sure if there's an available error code that would describe this NFS4ERR_OP_ILLEGAL perfectly, -EINVAL might be reasonable but I it's not very distinctive. Maybe we should add one to include/linux/errno.h? > > NFS4ERR_NOTSUPP is the correct return value if a server doesn't (yet) > support an operation. > > > Agreed. Just that we had a bug in the server that caused us to return NFS4ERR_OP_ILLEGAL for unimplemented ops rather than NFS4ERR_NOTSUPP. That's a condition I really want to be aware of while developing the server. Benny -- 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
