[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241025201011.GY10433@brightrain.aerifal.cx>
Date: Fri, 25 Oct 2024 16:10:11 -0400
From: Rich Felker <dalias@...c.org>
To: Alyssa Ross <hi@...ssa.is>
Cc: musl@...ts.openwall.com
Subject: Re: Prototypes without implementations
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..
>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.
Rich
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.
