On Dec 21, 2011, at 5:04 PM, Peter Staubach wrote: > By text based, you don't really mean encoding the binary structure as a string of ascii hex bytes, right? Bleah. No, I mean something akin to what is done for the other NFSD upcall and downcall arguments and results. A single set of decimal digits for simple arguments, and "keyword=value keyword=value,value" and so on for complex arguments. I recommend text because that is similar to what is used for every other modern user space API that NFSD has. > I would suggest that XDR encoding seems quite natural to use when passing binary structs around. To be clear, there is just one binary data item here, and that's nfs_client_id4. The other data items are integers, which have well-defined text representations. A new and separate API without any legacy baggage might be XDR, but text seems more appropriate here given the existence of other text APIs. I'm not religious about this, just highlighting a few design choices. > Thanx... > > ps > > > -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of Jeff Layton > Sent: Wednesday, December 21, 2011 4:59 PM > To: Jeff Layton > Cc: Chuck Lever; bfields@xxxxxxxxxxxx; steved@xxxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v3 4/5] nfsd: add a header describing upcall to nfsdcld > > 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 -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
