This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: _ioperm support for Arm
On 29/05/2019 18:17, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> On 29/05/2019 15:44, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>> [sysctl deprecation]
>>>
>>>>> The linker warnings happen only on some architectures right now (which
>>>>> use the “generic” Linux system call ABI).
>>>>
>>>> This is standard ENOSYS stub we emit for non-implemented symbols. I think
>>>> we will need both add __attribute_deprecated__ and create a new stub with
>>>> a different warning message (maybe "symbol is deprecated and it will be
>>>> removed in future versions").
>>>
>>> We have an explicit sysdeps/unix/sysv/linux/generic/sysctl.c override,
>>> though. I don't know why it was done this way. I think it predates the
>>> attempt to deprecate sysctl with the addition of the x32 ABI.
>>
>> My understanding is the linux/generic is aiming to mimic the current Linux
>> UAPI, so a new port would require to just add the folder on its Implies
>> folder.
>
> Right, and the sysctl stub there looks like a mistake in retrospect.
>
>>> Anyway, it doesn't matter for the upcoming deprecation.
>>
>> I would suggest to add a new stub, stub_deprecate, which similar to
>> stub_warning emit a linker message when the symbol is linked to state
>> is not safe to rely on it and most likely it will be removed in future
>> glibc version. Combined with __attribute_deprecated__ it should give
>> users enough warnings to fix it.
>
> Interesting idea. Maybe not stub_deprecate but
> deprecated_linker_warning or something like that. We already have
> something like that form mktemp.
We could use link_warning instead, deprecated_linker_warning would be
just a easier way (which concatenate the name to pre-defined message).
>
> Is it possible to disable these warnings for people who do not want to
> see them? If they cannot be disabled, that would be an argument against
> adding them.
I am not aware of any way to disable .gnu.warning. on ld, neither I could
find a way glancing binutils source code. However I do not consider this
an argument against because the object will still be created by binutils
in the end.
>
>> What I am not sure is for newer ports, do we really need to export
>> the symbol as ENOSYS?
>
> No, not really. The removal with the compat symbol mechanism will take
> care of that automatically for architectures with symbol baselines after
> the compat symbol activation.
>
> Until that, for new ports, we should just add an empty sysctl.c file.
> (The x32 hack is unnecessarily complicated.) Unfortunately, we missed
> doing this for C-SKY at all.
Right, I think we have plan then. How should we proceed regarding
deprecation warning and finally making it a compat symbol? Maybe 2 releases
with the warning and then finally moving to compat?