Re: _ioperm support for Arm

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 29/05/2019 11:03, Florian Weimer wrote:
> * Phil Blundell:
> 
>> On Wed, May 29, 2019 at 02:11:42PM +0200, Florian Weimer wrote:
>>> In the kernel, I only see a call to register_isa_ports in
>>> arch/arm/mach-footbridge/dc21285.c.
>>
>> Right, I think that functionality was only ever supported on
>> DC21285 platforms.  There were more of those than just NetWinder,
>> but they were all StrongARM (ARMv4).
>>
>> You're correct that it isn't practical for an ARMv4 machine to be 
>> EABI conformant because the EABI mandates interworking and ARMv4 
>> doesn't have BX/BLX, but last time I looked glibc did still have
>> all the right conditional guards in place to allow for compilation
>> on an ARMv4 platform.  I haven't checked recently though and it's
>> possible that it might have bit-rotted.  If we did want to make a
>> policy decision that glibc doesn't support older ARM architectures
>> anymore then there are probably quite a lot of #ifdefs that could
>> be eliminated.
> 
> There's this bug:
> 
>   Remove ARM old-ABI support
>   <https://sourceware.org/bugzilla/show_bug.cgi?id=13556>
> 
> I believe this removed core support for non-EABI platforms.
> 
> All the target triplets we test upstream have gnueabi in them, and these
> days, anything that is not built by build-many-glibcs.py in at least
> variant is not considered supported, I think.
> 
>> All that said, I don't imagine anybody would notice if the 
>> ioperm() support in glibc were to go away, and in the unlikely 
>> event that there is some application somewhere that relies on it, 
>> it wouldn't be very difficult to patch ioperm() into the 
>> application itself.  It doesn't interact with anything else 
>> inside glibc.
>>
>> Is there a particular reason for wanting to remove it, or is it 
>> just that it seems like useless cruft we could do without?
> 
> It's an internal consumer of the sysctl facility.  The sysctl facility
> has been removed on the Linux side and is not enabled by default.  I
> looked at the _ioperm code and wondered whether it makes sense to patch
> it to issue the system call directly (rather than using the sysctl
> wrapper).  But when I started looking where kernel support for the
> specific sysctl subtrees comes from, I noticed the Netwinder dependency.
> 
> We should get rid of sysctl support because it is really confusing to
> developers.  The current attempt at deprecation didn't work out.  Both
> RISC-V and C-SKY were added after the supposed deprecation, but
> accidentally received a stub implementation of the sysctl function in
> glibc.  Even on some older platforms (notably AArch64), there has never
> been kernel support.

Also, from previous Cauldron discussion, we should make the deprecation
in longer phases.  It also seems that compiler warning that symbol will
be deprecated in future releases is not a complete way to warn developers
to add configure build options take this consideration (the libgo example
with uname come to my mind). So maybe we use a different strategy for
sysctl, by deprecating in 2/3 releases and make it a compat symbol after
3/4 releases.