Re: [musl] Prototypes without implementations

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

Rich Felker <dalias@libc.org> writes:

> On Fri, Oct 25, 2024 at 10:01:37PM +0200, Alyssa Ross wrote:
>> <sys/io.h> 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 <sys/io.h> 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 <sys/io.h> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]