Rich Felker writes: > On Fri, Oct 25, 2024 at 10:01:37PM +0200, Alyssa Ross wrote: >> includes prototypes for iopl() and ioperm(), but not all >> architectures provide implementations, because the implementation is >> conditionally compiled only if SYS_ioperm is defined. This means that >> on aarch64, musl is providing prototypes without implementations, which >> is very surprising to me. >> >> musl provides these prototypes unconditionally since commit >> 0004ea613ac310daaee30c167112d796db33fa70: >> >> > fix breakage from introducing bits header for sys/io.h >> > >> > apparently some other archs have sys/io.h and should not break just >> > because they don't have the x86 port io functions. provide a blank >> > bits/io.h everywhere for now. >> >> Glibc only provides on alpha, ia64, i386, x86_64, of which >> musl supports only the latter two. It used to provide it on arm as >> well, with stub implementations (ioperm() returning ENOSYS, inb >> returning 0, …), but the header was dropped in Glibc 2.30. Linux (as of >> v6.11) has an ioperm syscall on x86, microblaze, mips, and powerpc, but >> on everything but x86, it's just a stub that returns ENOSYS. >> >> Some code in the wild I have found expects that it can use the existence >> of as a proxy for being able to use inb/outb, etc. Would it >> make sense for musl to match the Glibc behaviour of only providing >> sys/io.h on i386 and x86_64? Regardless, I think that the presense of >> unimplemented prototypes ought to be fixed somehow. > > Generally we aim not to provide different interfaces for different > archs. That principle has only been partly followed here. I'm not sure > if the status quo is preferable, or if we should add iopl/ioperm > functions that just ENOSYS on archs without them, or if we should do > something like you suggest and suppress them on archs that don't > have/need them. But I don't really see a good motivation for the last > option except trying to make badly behaving applications happy.. I think ENOSYS is probably the way to go, especially since (via the kernel) that's already happening on some architectures. > From the application side, using sys/io.h as proxy for existence of > inb/outb is just wrong. If they want to know if inb/outb exist, they > can probe those specifically: including the header and attempting to > compile and link a test program that uses the interface. Agreed.