On Wed, Oct 01, 2008 at 04:51:56PM -0400, bfields wrote: > 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 (Err, I think that parenthetical remark was meant to be a question. Apologies.) > 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
