On Wed, Oct 01, 2008 at 04:42:51PM -0400, Chuck Lever wrote: > On Oct 1, 2008, at Oct 1, 2008, 4:08 PM, J. Bruce Fields wrote: >> On Wed, Oct 01, 2008 at 03:40:05PM -0400, Chuck Lever wrote: >>> Right. I couldn't think of something simpler. >>> >>> rpc.statd has to continue to work with legacy kernels where the >>> first 4 >>> bytes of the opaque are a 32-bit sin_addr field and the following 12 >>> bytes are zero. >> >> Wait a minute, there's something not right there: rpc.statd shouldn't >> interpret the contents of the opaque field at all, should it? > > Yes, our rpc.statd and lockd should agree on the contents and > interpretation of the opaque field. The field is opaque because it's > internal content is not defined by a standard. It's a cookie, just like > a file handle. > > I would certainly *prefer* the use of an entirely arbitrary cookie, but > that's not the way Linux happens to work today. I'm pretty certain it does--at least on the rpc.statd size. (Any evidence to the contrary.) Sure, it means something to the kernel, but that's just for the kernel's convenience. We can do whatever we want in the kernel. --b. -- 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
