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

[Jim Rees <rees@umich.edu>]

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.

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.