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 62FC92157B for ; Thu, 11 Apr 2024 18:55:52 +0200 (CEST) Received: (qmail 32019 invoked by uid 550); 11 Apr 2024 16:55:45 -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 Received: (qmail 31984 invoked from network); 11 Apr 2024 16:55:45 -0000 Date: Thu, 11 Apr 2024 12:55:56 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20240411165556.GB4163@brightrain.aerifal.cx> References: <20240411142455.GA4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240411142455.GA4163@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] making termios BOTHER speeds work On Thu, Apr 11, 2024 at 10:24:56AM -0400, Rich Felker wrote: > Since it's come up again, I'm looking at what it would take to get > support for custom baud rates in termios working. This topic is > something of a mess, as it involves discrepancies between our termios > structure and the kernel termios/termios2 structures. > > Szabolcs Nagy did some of the initial research on the mismatched > definitions in 2016: https://www.openwall.com/lists/musl/2016/04/26/3 > > Basically, it looks like what happened was that we tried to match the > glibc generic ABI (an early goal of lots of stuff in musl) as long as > it lined up with the kernel termios (not termios2) ioctl structure, > but deviated when it wouldn't (powerpc had c_line and c_cc order > flipped and we followed kernel on that), and didn't do glibc > arch-specific mistakes (like mips omitting the __c_[io]speed fields). > > If we had used the kernel value of NCCS everywhere, rather than the > inflated glibc value of 32, we could add BOTHER support just by > attempting TCSETS2 using the caller's termios structure, and only > falling back if it doesn't work. In theory we *could* change to do > this now. The __c_[io]speed members are not in the public namespace, > and NCCS could be reduced to accommodate them as long as the overall > struct size was preserved. This might be ~ugly~ for programs built > with the old NCCS of 32, which might copy c_cc past its new end, but > they'd just be moving stuff to/from the reserved speed fields they > couldn't yet be using. The worst part about this seems to be that we'd > be introducing more arch-specific versions of bits/termios.h, since > the "generic" definition we have now actually has different layout > depending on the arch's alignment requirements. I think this only > affects m68k (where it's 2 rather than 4 byte alignment for int), so > maybe it's not a big deal to add just one. > > The alternative is to only use the caller-provided termios in-place in > the case where we can get by without termios2 interfaces: that is, > when either BOTHER is not set (classic POSIX baud flags), or TCSETS2 > is not defined (plain termios already supports BOTHER for this arch). > Otherwise, translate to a kernel termios2 form, which really requires > nothing other than knowing an arch-defined offset for the speed > fields. > > For going the other direction (tcgetattr) it's even easier: we're > allowed to clobber the caller buffer, so just try TCGETS2 and move the > speeds from their kernel offset into the libc member offsset. > > I think this second approach is probably better, but I'm open to > reasons why it might not be. One thing I hadn't even considered yet is how the application is expected to set custom speeds. We don't expose BOTHER, and while we could expose it and put the c_[io]speed members in the public namespace for direct access, it's not clear that this is the right way to do it. glibc's approach seems to be having cfset[io]speed accept values other than the symbolic B constants, which POSIX allows and mentions in the RATIONALE: There is nothing to prevent an implementation accepting as an extension a number (such as 126), and since the encoding of the Bxxx symbols is not specified, this can be done to avoid introducing ambiguity. https://pubs.opengroup.org/onlinepubs/9699919799/functions/cfgetispeed.html This seems like it's the better approach. It does have values 0-15 and 4096-4111 as impossible-to-set because they overlap with B constants, but these are not useful speeds. Of course it might be useful to look at what applications expect to be able to do. Looking at the existing code, it seems like Linux already had separate input baud encoded in the bits of c_cflag (CIBAUD mask), but we're not using that. It's not yet clear to me whether these work and whether we should be using them. POSIX is also unhelpful/wrong on how to determine if "split baud" is supported. The RATIONALE for cfgetispeed says: Setting the input baud rate to zero was a mechanism to allow for split baud rates. Clarifications in this volume of POSIX.1-2017 have made it possible to determine whether split rates are supported and to support them without having to treat zero as a special case. However, tcgetattr specifies: If the terminal device supports different input and output baud rates, the baud rates stored in the termios structure returned by tcgetattr() shall reflect the actual baud rates, even if they are equal. If differing baud rates are not supported, the rate returned as the output baud rate shall be the actual baud rate. If the terminal device does not support split baud rates, the input baud rate stored in the termios structure shall be the output rate (as one of the symbolic values). Which clearly gives the *same behavior* in both the case where split rates are supported but the same, and the case where split rates are not supported. I have no idea what they intended here. I think before this can move forward we need to have a better understanding of what POSIX is supposed to require here and what Linux actually does. Rich