Rich Felker <dalias@libc.org> writes:

> Can we use the remainder of this thread for figuring out the real
> status of this (what's with non-x86 archs that have the syscalls? are
> they used? what about archs that don't use them? do they have you mmap
> a device instead?) and whether there's some action that should be
> taken, rather than rehashing broad philosophy? :)

On all the other architectures where musl has SYS_ioperm defined, it's
mapped to sys_ni_syscall (ENOSYS), and has been at least since git was
introduced.

Glibc provides a fallback that uses /dev/mem on alpha, but no other
architecture.  In the past, it also provided an implementation for arm,
which was removed in the following commit:

	commit 6b33f373c7b9199e00ba5fbafd94ac9bfb4337b1
	Author: Florian Weimer <fweimer@redhat.com>
	Date:   Wed May 29 16:53:09 2019 +0200
	
	    arm: Remove ioperm/iopl/inb/inw/inl/outb/outw/outl support
	    
	    Linux only supports the required ISA sysctls on StrongARM devices,
	    which are armv4 and no longer tested during glibc development
	    and probably bit-rotted by this point.  (No reported test results,
	    and the last discussion of armv4 support was in the glibc 2.19
	    release notes.)

The functions remain on arm, but they are just ENOSYS stubs.

Does any of that make it any clearer what should be done in musl to
solve the prototypes without implementations problem?

I guess it does make sense for musl to define __SYS_ioperm on
microblaze, mips, powerpc and powerpc64 — it's in the kernel syscall
table for those architectures, even though as far as I can tell it has
never done anything other than return ENOSYS.