mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Alyssa Ross <hi@alyssa.is>
To: musl@lists.openwall.com
Subject: [musl] Prototypes without implementations
Date: Fri, 25 Oct 2024 22:01:37 +0200	[thread overview]
Message-ID: <878quc7xzy.fsf@alyssa.is> (raw)

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

<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.

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

             reply	other threads:[~2024-10-25 20:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25 20:01 Alyssa Ross [this message]
2024-10-25 20:10 ` Rich Felker
2024-10-25 21:38   ` Alyssa Ross
2024-10-26  1:21     ` Re[2]: " Laurent Bercot
2024-10-26  1:57       ` Thorsten Glaser
2024-10-26  2:11         ` Rich Felker
2024-10-26  8:26       ` Markus Wichmann
2024-10-26 10:28         ` Re[2]: " Laurent Bercot
2024-10-26 13:22           ` Markus Wichmann
2024-10-26 22:08             ` Thorsten Glaser
2024-10-26 23:03               ` Rich Felker
2024-10-30  9:28                 ` Alyssa Ross
2024-10-30 12:37                   ` enh
2024-10-26 23:35             ` Re[2]: " Laurent Bercot
2024-10-27 22:43             ` Yao Zi
2024-10-26 10:10       ` Robert Clausecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878quc7xzy.fsf@alyssa.is \
    --to=hi@alyssa.is \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).