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 7F44E2F6D1 for ; Sun, 27 Oct 2024 01:04:04 +0200 (CEST) Received: (qmail 19579 invoked by uid 550); 26 Oct 2024 23:03:59 -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 19543 invoked from network); 26 Oct 2024 23:03:58 -0000 Date: Sat, 26 Oct 2024 19:03:50 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20241026230350.GA10433@brightrain.aerifal.cx> References: <878quc7xzy.fsf@alyssa.is> <20241025201011.GY10433@brightrain.aerifal.cx> <874j4zoob8.fsf@alyssa.is> <2bb1f0ce-d210-5f5f-2f8a-dff1b5cfc736@evolvis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2bb1f0ce-d210-5f5f-2f8a-dff1b5cfc736@evolvis.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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