Talpey, Thomas wrote:
> "RPCB_" prefix: They're (with this patch) part of the rpcbind api. The prefix
> seems logical to me... 

Well, that's a fair argument, since the idea of netid is defined in RFC 
1833, which is about rpcbind specifically.  However, the globally scoped 
RPC-related identifiers are usually named RPC_... and you are now making 
use of these things in the transport layer as well as in rpcbind.

It's a nit, I guess.

> when you say "the same as the other RPC..." do you
> mean they should be "RPC_NETID_..."?

Yes.

> RPCB_MAXNETIDLEN: Sure, I'll move it. It is, after all, a limit on the string
> passed as the netid, i.e. part of the API. But let me ask this. It really isn't
> necessary, the code in rpcbind can easily accommodate longer strings. Is
> it worth coding the extra generality? The reason I didn't is because (as the
> comment mentions) there aren't any longer strings defined by any RFC.

We need to know the maximum size to compute the largest possible size of 
the RPC buffer needed for the request.  See the definition of 
RPCB_netid_sz.  Those are all added together to get the largest possible 
request size, and that's used to compute the largest possible buffer size.

Using a macro documents what the heck that number is.  "4?  4 what?"  I 
was asked at the time this was submitted to use macros instead of 
open-coded integers, and I tend to agree that looks better.

> clnt.h vs msg_prot.h: After discovering the rpcbind calls defined in clnt.h,
> and also seeing rpc goop in there, it felt more correct than msg_prot.h,
> which is pretty much about rpc marshaling and error codes. All the other
> rpcbind stuff is in clnt.h, and most all clnt's need to call rpcbind to find
> their port. That's my rationale.

The rpcbind function calls are defined in clnt.h because they are part 
of the RPC client API, specific to Linux.

Netids are standardized on-the-wire marshaled values, so they definitely 
belong in msg_prot.h, which as you say, contains marshaling and error 
code definitions.