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: _ioperm support for Arm


* 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.

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.

> 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.

Thanks,
Florian


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