[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241026230350.GA10433@brightrain.aerifal.cx>
Date: Sat, 26 Oct 2024 19:03:50 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Prototypes without implementations
On Sun, Oct 27, 2024 at 12:08:25AM +0200, Thorsten Glaser wrote:
> On Sat, 26 Oct 2024, Markus Wichmann wrote:
>
> >See above. Failing with ENOSYS and no side effects is a perfectly
> >conforming implementation of most POSIX functions.
>
> Insisting on this ivory tower opinion will just make people
> mark your software as buggy and move on.
>
> For most functions, it’s reasonable to check for presence,
> and if so, enable codepaths that do:
>
> if (pselect(…) == -1) {
> if (errno == EINTR) {
> // special handling
> }
> err(1, "pselect");
> }
>
> The vast majority of software, OSS and not, works this way.
> If a basic function in a standard is there it better function.
>
> Linux’ getrandom() is an offensive exception to that and better
> stay the only one.
This thread has veered really off-topic. I haven't read it in full,
but based on what it seems to be about, a few remarks:
- I don't buy that ENOSYS buys you a license to omit parts of POSIX
you don't want to implement. Yes there's license to have additional
errors not defined in the standard, but the only reasonable
interpretation is that these should be for concrete conditions that
can be remedied. At the very least, an interface always failing is
bad QoI. As an example, I don't claim running on a nommu system,
where fork() will necessarily ENOSYS, gives a POSIX-conforming
environment; it's a POSIX subset. IIRC part of the rationale text
addresses that and agrees with my interpretation here.
- pselect ENOSYS? Come on. This is 2024, almost 2025, not 1999.
(Unless I'm misremembering it was added in POSIX 2001.)
- Back to extension interfaces (or very recent standards) which might
or might not be available at runtime: Whether availability of a
particular such interface is reasonable to defer to runtime really
depends on what the interface is and what it's being used for.
Trying to make broad sweeping generalizations does not seem helpful,
and particularly, does not seem relevant to the ioperm/iopl topic.
- That said, yes, whether an interface is available at the library
level, and whether it works on the machine you happen to be running
on later, can differ, and this is something where "musl policy"
(using the term very loosely, in the sense of what we recommend to
projects when trying to get something fixed) is that, unless the
standard says the interface and functionality is always present, you
should both check for it at configure-time/build-time, and be
prepared at runtime for the possibility that it might not be
supported or might not support all features on the running system. I
would expect software using iopl/ioperm already needs to be prepared
for the possibility that they could fail for permissions reasons,
and should avoid calling them anyway unless it knows it needs to
perform userspace hardware IO. So I'm not sure how this matters or
how an ENOSYS here would be any different from EPERM -- it's just
another reason you can't do IO as a user process.
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? :)
Rich
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.
