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