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 1EF312140B for ; Thu, 11 Apr 2024 16:24:51 +0200 (CEST) Received: (qmail 23631 invoked by uid 550); 11 Apr 2024 14:24:44 -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 23592 invoked from network); 11 Apr 2024 14:24:44 -0000 Date: Thu, 11 Apr 2024 10:24:56 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20240411142455.GA4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] making termios BOTHER speeds work 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. Rich