[PATCH] Linux: Remove <sys/sysctl.h> and the sysctl function

Adhemerval Zanella adhemerval.zanella@linaro.org
Thu Mar 12 14:33:14 GMT 2020



On 12/03/2020 05:15, Florian Weimer wrote:
> * Vineet Gupta via Libc-alpha:
> 
>> On 3/11/20 1:19 PM, Zack Weinberg wrote:
>>> So I withdraw my objections to your original patch.  We can always put
>>> sys/sysctl.h back in the future if someone does the work to write the
>>> emulation.
>>
>> My 2 cents. Can we _not_ remove the header per-se. This can certainly cause
>> arbitrary packages to build time fail (vs. runtime failure from sysctl returning
>> -1 or some such). Propagation of such fixes in build systems it may take a while.
>> Consider my personal woe with stime removal in context of Buildroot/busybox.
>> Despite them fixed in busybox not all moving parts are aligned still and we have
>> to carry such patches locally to be able to even build glibc 2.31+ there.
> 
> Why aren't those patches upstream yet?  (I'm not blaming you, I'm just
> trying to understand what is going on.)
> 
> Are you in a special position becaue you have to use a newer glibc for
> your port, and everybody else using this distribution is sticking with
> an older glibc?
> 
> glibc's approach to removals is inconsistent at best.  stime was never
> deprecated and removed directly, for example.  There is also the issue
> that configure scripts ignore deprecation warnings, which then can
> lead to build issues later one, something that does not happen with
> removed interfaces (which are obviously not detected by configure
> scripts).

stime removal was done without deprecation mainly because it has
been an obsolete function for a long time and it would not make
sense to make a y2038 safe version of it. Since y2038 was not done
for 2.31, maybe we could instead instead had mark it as deprecated
remove it on 2.32 (along with the header).

> 
> And specific to sysctl, the removal of the header and function
> actually fixes bugs in a few packages.
> 

It is always a risk to remove an installed headers and for this
one specifically I agree with you, it is time to move forward 
and stop providing it.


More information about the Libc-alpha mailing list