Re: _ioperm support for Arm

[Florian Weimer <fweimer at redhat dot com>]

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

Thanks,
Florian