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

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Dec 22, 2011 at 10:20:51AM -0500, Jim Rees wrote:
> Jeff Layton wrote:
> 
>   Now that I've started looking at actually implementing this, I'm
>   leaning toward keeping this as a packed binary struct. The upcalls to
>   which you refer mostly use the cache_* interfaces in the kernel, and
>   the actual upcall "pipes" are in /proc. That code is already set up to
>   use primarily text based interfaces so it makes sense there.
>   
>   I looked at using that here and determined that the cache_* interface
>   was not well suited to this task. Those are geared toward interfaces
>   (like exportfs or mountd) where the information is primarily stored and
>   manipulated in userspace and the kernel upcalls to fetch that info and
>   populate its cache.
>   
>   In this case, the info is mostly coming from kernel space originally
>   and I believe that rpc_pipefs was better suited for this task. The
>   upcalls that use rpc_pipefs almost universally use a binary struct to
>   pass data between userspace and the kernel.
> 
> Having recently added a new rpc_pipe upcall for idmapd, my only suggestion
> is that you think about compatibility issues if the message format changes.
> Ideally you want any combination of new/old * kernel/user to work.  But I
> suspect you've already thought about this.

Yes, I think the 8-bit version and command numbers give us what we'd
need.  We should make sure the daemon returns a well-defined error in
the case it doesn't know about a new command or version number.  And
then any backwards compatibility problem can be solved with sufficient
application of switch statements.  Hopefully unnecessary, but should be
safe.

So the current format encoding looks OK to me.  Unless someone has a
real slam-dunk of an argument I'd rather stick with it for now.

--b.

> I see no harm in using binary for an interface that's only intended for a
> particular user daemon (assuming you solve the compatibility problem).  Text
> is useful for things in /proc that someone might want to manipulate using
> their own tool.  For something like idmapd I don't think a text interface is
> necessary.  No one is going to write their own idmapd, and if they do, the
> binary upcall interface will be the least of their worries.  The same may be
> true of nfsdcld.