This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option


On Mon, Dec 13, 2010 at 9:50 AM, Steve Dickson <SteveD@redhat.com> wrote:
> Hi,
>
> Any thoughts on deprecating the rpc code in glibc?

I'm in favor of removing the RPC code from glibc in favor of the
libtirpc library implementation.  I don't mind doing this via a number
of careful steps that may take some time in order to reduce confusion
and preserve backwards-compatibility.

However, __attribute__((deprecated)) applies just to the API (the
function names and synopses), not to its implementation.  Deprecation
means we don't want applications to use the functions in this API in
_any_ form from _any_ library.  We're not deprecating the API, we're
shifting the implementation to another library.  libtirpc has all of
the legacy RPC API built into it, so applications can and should
continue to use the legacy RPC API as implemented by libtirpc.

There may be some minor ABI incompatibilities with the libtirpc
implementation of the legacy RPC API.  This is no more serious in my
view than revving glibc and finding a bug or incompatibility in its
RPC implementation.

In short, I think deprecating the legacy RPC API in the glibc headers
would unnecessarily confuse developers, especially if the libtirpc RPC
headers take the place of the glibc RPC headers under /usr/include.

Is it possible to create a build-time option to include the RPC
implementation in glibc, and to install the RPC headers and man pages
at install time?  Then distributors can choose a glibc with RPC, or
one without.  Eventually, when distributors are comfortable with the
new RPC implementation, the build-time option and the RPC
implementation would be removed from glibc entirely.  The fact that
applications will require a new extra library to build correctly
should be enough to let application developers know they need to look
for potential trouble.

> The thread in its entirety:
> ? ?http://marc.info/?l=linux-nfs&m=129200137524049&w=2
>
> steved.
>
> -------- Original Message --------
> Subject: Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option
> Date: Fri, 10 Dec 2010 12:10:14 -0500
> From: Andrew J. Schorr <ajschorr@alumni.princeton.edu>
> To: Chuck Lever <chuck.lever@oracle.com>
> CC: Steve Dickson <SteveD@redhat.com>, linux-nfs@vger.kernel.org
>
> On Fri, Dec 10, 2010 at 12:01:51PM -0500, Chuck Lever wrote:
>> If we go with just the evidence at hand: Andrew says he can rebuild his application. ?Thus, so far there is no specific requirement to expand "-i". ?IMO we should wait until there is, in the most noble of Linux traditions.
>>
>
> To be fair, this will require porting work on my side. ?It is not a completely
> trivial recompile, since some of the data structures have changed a little
> bit.
>
> I don't know whether removing from glibc is a great idea because of this
> aspect. ?The new TIRPC code is not 100% compatible (for example, struct XDR has
> some differences in the xdr_ops). ?I personally think that adding
> '__attribute__ (( __deprecated__ ))' to all the function prototypes in
> /usr/include/rpc/*.h would be a good first step, and also add a comment to the
> header files directing people to port their code to the new tirpc API.
>
> Anyway, that's my 2 cents.
>
> Regards,
> Andy
>
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Libtirpc-devel mailing list
> Libtirpc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
>



-- 
"What is a pancake, if not a big, fluffy Eucharist?"
?-- Stephen Colbert


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]