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=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, 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 0028130BD0 for ; Wed, 30 Oct 2024 13:38:00 +0100 (CET) Received: (qmail 32034 invoked by uid 550); 30 Oct 2024 12:37:55 -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 31995 invoked from network); 30 Oct 2024 12:37:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1730291866; x=1730896666; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bR0Q70MK8WxdFNBIWBJgBIub52H7iZteqPf3aLzhOd0=; b=S1MCpSiNoPBvFOTX8nCbNsPazRVxPYoP8QqK8TZDgGcDnl/uPSYwrD4GAMMq4ZEgRE 6sZhNeLRKqzbWSwIbm3z9kK7xfU9NDcrU7BPIGRcwjYgnqwXIoduE10R93lu9V0IyTbO u6BvpowuqDNHv59tKQWw/v7wqzCqoUScvDvtJZQiqvHXc7cfVVh9ba3htEjXxVCooIQC MEL5kmXJJauErAIMNjfEm0twr014M5r0E66IHlxM8Mss8l37DZcuUnbYbsKlSIsJVakg iBHDCZ+IS7935OIzPPIYsPHVu5vV+EDaZs0aTMn48Xb0V4DGIb6plGiQdYhNAGP89bnp 7U9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730291866; x=1730896666; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bR0Q70MK8WxdFNBIWBJgBIub52H7iZteqPf3aLzhOd0=; b=iRYak/QeVg+OnUYnzbj7HjWRwbjQHmolwokRFiM9rzVirOLUUnDlU7aK/4+jCdpb8I +WJqHHQ5frJb31OFes0xiA6Iu4px7KJKAq+d1MtCM4XjvKTILHc8AnM4YxHw34EIi3aD EYG//hKAttbsSjp9jlMaGsXzB6dq2bRmvCMhkFj5tqSF4yJsXTmXrJXb7U7h8/aH7SwN 5k7uYdZ0Pc1LUSTg2G7Eqk5KULkkmjwYAh0P0odv6c2Qs89F1S4U/U7kT0SjT7bkqVbo ie8pnc78bGeygHJ8puyMbBaVjqWKPKf9Gg3vRvDzn3BaNJBX9RXIQWzgkvXMhbuWaMj5 V3EQ== X-Gm-Message-State: AOJu0Yx6gxZYsQiTUDPlPHAFZiINF9sK84w64kSGnuI3UG6BgYKOS4Pz 3x7olyjX0sfwU3OIwAOD+D2pxuYczKM4td+XGMHdVMazGpihPx77oOiz2kKeqHZ4EcdpFHoK5fd zEvs3ZV/SUxuHAA2j+hfqOGgSZah7XbdRcgKFz0fp2d2e8HUF9yE3scw= X-Google-Smtp-Source: AGHT+IHVx0EQLvW02fVJozandwzSMj6uwAM5m0WzQtqinapa4BB02luzsQz+76ObcrZ0Ad4emuPK5CVqXS9HE03N9iY= X-Received: by 2002:a05:6358:5699:b0:1b8:203b:db84 with SMTP id e5c5f4694b2df-1c3f9d4a73fmr755874955d.4.1730291865650; Wed, 30 Oct 2024 05:37:45 -0700 (PDT) MIME-Version: 1.0 References: <878quc7xzy.fsf@alyssa.is> <20241025201011.GY10433@brightrain.aerifal.cx> <874j4zoob8.fsf@alyssa.is> <2bb1f0ce-d210-5f5f-2f8a-dff1b5cfc736@evolvis.org> <20241026230350.GA10433@brightrain.aerifal.cx> <87ldy67xdg.fsf@alyssa.is> In-Reply-To: <87ldy67xdg.fsf@alyssa.is> From: enh Date: Wed, 30 Oct 2024 08:37:30 -0400 Message-ID: To: musl@lists.openwall.com Cc: Rich Felker Content-Type: multipart/alternative; boundary="000000000000039cde0625b0f872" Subject: Re: [musl] Prototypes without implementations --000000000000039cde0625b0f872 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable fwiw, this came up for Android recently... we'd never had the header before but the https://blog.chromium.org/2024/06/building-faster-smarter-chromebook.html work meant we needed new x86-only stuff for the first time in a decade. we basically went with this: #if defined(__NR_iopl) static __inline int ioperm(unsigned long __from, unsigned long __n, int __enabled) { return syscall(__NR_ioperm, __from, __n, __enabled); } #endif (which answers the "some architectures" part, even though for Android that's only x86/x86-64.) here's my commit message with more rationale for why i made them static inlines: """ Add . This is unusual in being inline-only, but these are (a) trivial functions, (b) ancient functions, and (c) unusable by apps. Plus they're arriving just too late for API 35, which definitely influenced by "this is silly" decision! They're also x86/x86-64 only, though that's a neutral argument because it would mean almost no-one will be affected no matter what choice we make here. There is an argument for going the usual "callers should just have their own header-only implementation that they `-include` on the compiler command line" route, but the x86/x86-64 I/O port stuff isn't going away just yet, and LTP was also already working around the absence of these. """ https://android-review.googlesource.com/c/platform/bionic/+/3135242 On Wed, Oct 30, 2024 at 5:29=E2=80=AFAM Alyssa Ross wrote: > Rich Felker writes: > > > Can we use the remainder of this thread for figuring out the real > > status of this (what's with non-x86 archs that have the syscalls? are > > they used? what about archs that don't use them? do they have you mmap > > a device instead?) and whether there's some action that should be > > taken, rather than rehashing broad philosophy? :) > > On all the other architectures where musl has SYS_ioperm defined, it's > mapped to sys_ni_syscall (ENOSYS), and has been at least since git was > introduced. > > Glibc provides a fallback that uses /dev/mem on alpha, but no other > architecture. In the past, it also provided an implementation for arm, > which was removed in the following commit: > > commit 6b33f373c7b9199e00ba5fbafd94ac9bfb4337b1 > Author: Florian Weimer > Date: Wed May 29 16:53:09 2019 +0200 > > arm: Remove ioperm/iopl/inb/inw/inl/outb/outw/outl support > > Linux only supports the required ISA sysctls on StrongARM > devices, > which are armv4 and no longer tested during glibc development > and probably bit-rotted by this point. (No reported test > results, > and the last discussion of armv4 support was in the glibc 2.1= 9 > release notes.) > > The functions remain on arm, but they are just ENOSYS stubs. > > Does any of that make it any clearer what should be done in musl to > solve the prototypes without implementations problem? > > I guess it does make sense for musl to define __SYS_ioperm on > microblaze, mips, powerpc and powerpc64 =E2=80=94 it's in the kernel sysc= all > table for those architectures, even though as far as I can tell it has > never done anything other than return ENOSYS. > --000000000000039cde0625b0f872 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
fwiw, this came up for Android recently... we'd never = had the header before but the=C2=A0https://blog.chromium.org/202= 4/06/building-faster-smarter-chromebook.html work meant we needed new x= 86-only stuff for the first time in a decade.

we basical= ly went with this:

#if defined(__NR_iopl)
stati= c __inline int ioperm(unsigned long __from, unsigned long __n, int __enable= d) {
=C2=A0 return syscall(__NR_ioperm, __from, __n, __enabled);
}#endif

(which answers the "some architec= tures" part, even though for Android that's only x86/x86-64.)

here's my commit message with more rationale for w= hy i made them static inlines:

"""<= /div>
Add <sys/io.h>.

This is unusual in being inline-only= , but these are (a) trivial functions, (b) ancient functions, and (c) unusa= ble by apps. Plus they're arriving just too late for API 35, which defi= nitely influenced by "this is silly" decision! They're also x= 86/x86-64 only, though that's a neutral argument because it would mean = almost no-one will be affected no matter what choice we make here.

T= here is an argument for going the usual "callers should just have thei= r own header-only implementation that they `-include` on the compiler comma= nd line" route, but the x86/x86-64 I/O port stuff isn't going away= just yet, and LTP was also already working around the absence of these.
"""


On Wed, Oct = 30, 2024 at 5:29=E2=80=AFAM Alyssa Ross <hi@alyssa.is> wrote:
Rich Felker <dalias@libc.org> writes:

> Can we use the remainder of this thread for figuring out the real
> status of this (what's with non-x86 archs that have the syscalls? = are
> they used? what about archs that don't use them? do they have you = mmap
> a device instead?) and whether there's some action that should be<= br> > taken, rather than rehashing broad philosophy? :)

On all the other architectures where musl has SYS_ioperm defined, it's<= br> mapped to sys_ni_syscall (ENOSYS), and has been at least since git was
introduced.

Glibc provides a fallback that uses /dev/mem on alpha, but no other
architecture.=C2=A0 In the past, it also provided an implementation for arm= ,
which was removed in the following commit:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 commit 6b33f373c7b9199e00ba5fbafd94ac9bfb4337b1=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author: Florian Weimer <fweimer@redhat.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0Wed May 29 16:53:09 2019 +020= 0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 arm: Remove ioperm/iopl/inb/inw/i= nl/outb/outw/outl support

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Linux only supports the required = ISA sysctls on StrongARM devices,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which are armv4 and no longer tes= ted during glibc development
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and probably bit-rotted by this p= oint.=C2=A0 (No reported test results,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and the last discussion of armv4 = support was in the glibc 2.19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 release notes.)

The functions remain on arm, but they are just ENOSYS stubs.

Does any of that make it any clearer what should be done in musl to
solve the prototypes without implementations problem?

I guess it does make sense for musl to define __SYS_ioperm on
microblaze, mips, powerpc and powerpc64 =E2=80=94 it's in the kernel sy= scall
table for those architectures, even though as far as I can tell it has
never done anything other than return ENOSYS.
--000000000000039cde0625b0f872--