From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 706CE2E78A for ; Fri, 25 Oct 2024 22:10:25 +0200 (CEST) Received: (qmail 24434 invoked by uid 550); 25 Oct 2024 20:10:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 24390 invoked from network); 25 Oct 2024 20:10:20 -0000 Date: Fri, 25 Oct 2024 16:10:11 -0400 From: Rich Felker To: Alyssa Ross Cc: musl@lists.openwall.com Message-ID: <20241025201011.GY10433@brightrain.aerifal.cx> References: <878quc7xzy.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <878quc7xzy.fsf@alyssa.is> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Prototypes without implementations On Fri, Oct 25, 2024 at 10:01:37PM +0200, Alyssa Ross wrote: > 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 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 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