RE: [PATCH v3 4/5] nfsd: add a header describing upcall to nfsdcld

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I will need to disagree with the assertion regarding XDR and the packed struct.  XDR can handle a versioned struct very neatly.  It can do so just as easily as text string parsing and with greatly reduced overhead.

		Ps


-----Original Message-----
From: Jeff Layton [mailto:jlayton@xxxxxxxxxx] 
Sent: Wednesday, December 21, 2011 5:28 PM
To: Peter Staubach
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 17:04:02 -0500
Peter Staubach <pstaubach@xxxxxxxxxxx> wrote:

> By text based, you don't really mean encoding the binary structure as a string of ascii hex bytes, right?  Bleah.
> 
> I would suggest that XDR encoding seems quite natural to use when passing binary structs around.
> 

No, I was thinking along the lines of encoding the struct fields as key/value pairs in a string:

    "ver=1,cmd=create,clname=0x1a012bd..."

...binary stuff like the nfs_client_id4 would be hex encoded. Integers would be converted to text representations, etc.

I think if we're going to go to the trouble of encoding this stuff at all, it makes sense to do it in as flexible a manner as possible.

Now that I think about it, using XDR has little benefit over the current packed binary struct. If we ever need to rev the format, it'll be just as much of a pain. With key/value pairs, we should be able to ensure that a mismatch between kernel and userspace versions is more easily dealt with.

> 
> -----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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux