On Wed, 21 Dec 2011 16:48:10 -0500 Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Wed, 21 Dec 2011 16:37:30 -0500 > Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > > > On Dec 21, 2011, at 4:33 PM, Jeff Layton wrote: > > > > > On Wed, 21 Dec 2011 15:45:01 -0500 > > > Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > > > >> > > >> On Dec 21, 2011, at 3:34 PM, Jeff Layton wrote: > > >> > > >>> The daemon takes a versioned binary struct. Hopefully this should allow > > >>> us to revise the struct later if it becomes necessary. > > >> > > >> This breaks the pattern of using text-based up- and downcalls in NFSD. I assume this is binary because nfs_client_id4 is a string of opaque bytes? > > >> > > > > > > That's the main reason. We could, of course encode that string in hex or > > > something, and decode it on the other end. No one has presented a > > > strong argument for doing it that way as of yet though. > > > > > > If anyone feels strongly about that, then it would be helpful to have > > > them pipe up now and state why they do... > > > > <pipe>Because binary data structures are difficult to work with over time, which is why other NFSD user space interfaces are text-based.</pipe> > > > > ;-) > > > > *sigh* that was the sort of comments I was hoping to get out of the RFC > postings. But ok... > > I'll see about respinning the whole thing with either a text-based or > XDR-based upcall/downcall format. That'll take a while, but I'll see if > I can get it in shape in time for 3.3. > ...and while we're discussing it. Does anyone have thoughts on which would be better? I'd probably prefer a text-based format. That's more flexible but is also going to be more verbose. I think we're still well under a page with these requests even in text however so I don't really see that as a problem. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
