[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <878quc7xzy.fsf@alyssa.is>
Date: Fri, 25 Oct 2024 22:01:37 +0200
From: Alyssa Ross <hi@...ssa.is>
To: musl@...ts.openwall.com
Subject: Prototypes without implementations
<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.
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.
