On Jul 27, 2011, at 10:26 PM, Ian Kent wrote: > On Tue, 2011-07-26 at 23:30 -0400, Chuck Lever wrote: >>>> >>>> For IPv6 support, use functions that are part of the modern libtirpc >>>> API. This is described in Sun doc 816-1435. You probably will be >>>> most successful with the "simplified interface" which is described in >>>> Chapter 4. You might need somewhat more extensive surgery since I'm >>>> guessing you have separate code paths to invoke the IPv4 and IPv6 >>>> legacy RPC functions; generally speaking that should not be needed >>>> when using the libtirpc API. >>> >>> I doubt the simplified interface will be adequate since this code was >>> written because of a need for greater control over timeouts. Perhaps >>> that won't be the case, I don't know yet. >> >> If you want control over connection timeouts, use the expert-level or >> bottom-level interfaces. Otherwise you can set per-RPC timeouts when >> clnt_call(3t) is invoked. nfs-utils has some example code >> (support/nfs/rpc_socket.c is one place to look). >> >>> Your suggestion amounts to saying I need to re-write all my RPC >> code. >> >> The substantial change with client-side TI-RPC is how CLIENTs are >> created. The other RPC operations are similar or the same as they >> were with the legacy API. Once you get over getnetconfigent(3t) it's >> really not as bad as it looks. >> > > Umm ... > > Why is __rpcb_findaddr() declared in the public header files but not > defined anywhere is the source? > > Why is __rpcb_findaddr_timed() defined in the source but not defined in > the public header files?
This version of libtirpc was split from the Sun version over a decade ago when the code was immature. So you're going to find this kind of thing in many places. The TI-RPC API is defined in 816-1435. You really shouldn't consider using any of the interfaces defined in the headers but not in that doc, as those are internal interfaces and can change. On the other hand, we have at least two important RPC-based applications that can make use of this interface. I wonder if it makes sense to harden that API but leave it hidden, so apps external to the library can depend on it. Such apps would not be portable away from Linux nor to Linux distributions that don't have libtirpc yet. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
