This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option
On Tue, Dec 14, 2010 at 11:47 AM, Steve Dickson <SteveD@redhat.com> wrote:
>
>
> On 12/14/2010 11:26 AM, Thomas Schwinge wrote:
>> Hallo!
>>
>> On Mon, Dec 13, 2010 at 10:45:55PM -0500, Ulrich Drepper wrote:
>>> On Mon, Dec 13, 2010 at 17:52, Steve Dickson <SteveD@redhat.com> wrote:
>>>> This sounds very reasonable... What is the next step?
>>>
>>> First, the Hurd people have to say what they want to do. ?If they go
>>> along then no specialization is needed.
>>
>> To clarify: did you have anything specific in mind? ?I don't know why we
>> would want to diverge? ?(There is nothing Hurd or Mach-specific in the
>> SUN RPC code, unless I'm totally confused?)
> We, the NFS community, no longer need or used the SUN RPC code
> in glibc. We needed IPv6 support so we built and now support our
> own RPC library, called libtirpc.
>
> So as not to confuse people that are moving legacy apps to
> Linux: see http://marc.info/?l=linux-nfs&m=129200137524049&w=2
> we would like you to deprecate your old header files
> in /usr/include/rpc and point people to the new header
> files in /usr/include/tirpc.
I'd like the headers under /usr/include/tirpc/{rpc,rpcsvc} to be
moved, replacing the headers in /usr/include/{rpc,rpcsvc}.
/usr/include/tirpc is a non-standard location for these RPC headers.
Porting RPC applications will be made simpler by putting the RPC
headers in the conventional place.
> Basically we would be taking over all RPC library support...
> Something, I believe, you guys have wanted for a long time...
In addition to providing the new TI-RPC API, libtirpc also provides a
legacy RPC API (the same RPC API provided by glibc today).
There are changes to libtirpc's legacy implementation to make it
compatible with rpcbind, a replacement for portmap. libtirpc doesn't
work well with portmap today, but there are some changes in the works
to make it more compatible. We would prefer that everyone adopt
rpcbind instead, but realize that may not be practical.
--
"What is a pancake, if not a big, fluffy Eucharist?"
?-- Stephen Colbert