[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJgzZoqBkZdxvRSskGZCm7-Q+-ja32LB0+FJZgtFknOCRb1LYA@mail.gmail.com>
Date: Wed, 30 Oct 2024 08:37:30 -0400
From: enh <enh@...gle.com>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>
Subject: Re: Prototypes without implementations
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 <sys/io.h>.
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 AM Alyssa Ross <hi@...ssa.is> wrote:
> Rich Felker <dalias@...c.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
> > 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 <fweimer@...hat.com>
> 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.19
> 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 — it's in the kernel syscall
> table for those architectures, even though as far as I can tell it has
> never done anything other than return ENOSYS.
>
Content of type "text/html" skipped
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.
