On Fri, 2009-08-14 at 15:28 -0400, Trond Myklebust wrote: > No, it won't. The encode_*/decode_* routines reflect unique operations. > There is little or no overlap between what they encode/decode, so there > isn't much room for sharing macros between them. > Instead, we attempt to describe each encode_*/decode_* routine using its > own *maxsz macro. > > The exceptions to the 'no sharing' rule are sub-objects like stateids, > verifiers, and session ids. There we _do_ use macros both in the > reserve_space() calls, and in the ensuing opaque_encode/decode call. > However as you saw in the patch series, a better alternative is to give > them their own unique encode_stateid/decode_stateid routine that can be > checked once and for all against > encode_stateid_maxsz/decode_stateid_maxsz. By the way, I wouldn't be opposed to moving the definitions of the *maxsz macros down, so that each one is next to the function that it describes. That would facilitate the process of checking at a glance whether or not the buffer memory allocation and XDR code expectations match one another. It's not too urgent a project, though. Trond -- 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
