[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874j4zoob8.fsf@alyssa.is>
Date: Fri, 25 Oct 2024 23:38:51 +0200
From: Alyssa Ross <hi@...ssa.is>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Prototypes without implementations
Rich Felker <dalias@...c.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.
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
