This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] sunrpc: Do not unregister services if not registered [BZ #5010]
On 02/20/2017 08:14 AM, Florian Weimer wrote:
> * Florian Weimer:
>
>> The change in commit 718946816cf60374f9d8f674d3ed649fdb33205a
>> has no effect because of two bugs which cancel each other out:
>> The svc_is_mapped condition is inverted, and svc_is_mapped
>> always returns false because the check is performed after
>> the service has already been unregistered. As a result,
>> pmap_unset is called unconditionally, as before.
>>
>> 2017-02-08 Florian Weimer <fweimer@redhat.com>
>>
>> [BZ #5010]
>> * sunrpc/svc.c (svc_is_mapped): Remove.
>> (svc_unregister): Obtain mapped status while the service is still
>> registered.
>> * sunrpc/Makefile [have-thread-library] (tests): Add
>> tst-svc_register.
>> (tst-svc_register): Link against libc.so explicitly and the thread
>> library.
>> * sunrpc/tst-svc_register.c: New file.
>
> A completely different approach would remove this functionality
> altogether (and realign the code with libtirpc).
>
> Any preferences? Thanks.
I prefer your patch.
My thoughts on SunRPC are:
* Fix latent bugs.
* No new features.
* Eventual full deprecation.
There are sufficient differences between SunRPC and TIRPC that an application
is better served by being ported, than for us to slowly align SunRPC to TIRPC.
If the application hasn't been ported to TIRPC and it is because of lack of
resources, then any change we make will cause problems when rebuilding the
application.
If instead the application hasn't been ported to TIRPC and it is because of a
lack of a key SunRPC feature, then we'll never fix that because we don't want
to keep investing in SunRPC. It is legacy code for legacy applications.
The bug fixes are in the grey zone and should be fixed to keep existing
applications from failing, or to cause them to fail more gracefully.
That's my preference.
--
Cheers,
Carlos.