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 895CE235A5 for ; Thu, 11 Apr 2024 19:29:56 +0200 (CEST) Received: (qmail 17785 invoked by uid 550); 11 Apr 2024 17:29: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 17743 invoked from network); 11 Apr 2024 17:29:44 -0000 Date: Thu, 11 Apr 2024 13:29:56 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20240411172956.GC4163@brightrain.aerifal.cx> References: <20240411142455.GA4163@brightrain.aerifal.cx> <20240411165556.GB4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240411165556.GB4163@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 12:55:56PM -0400, Rich Felker wrote: > 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. OK, no, it doesn't. Only the nonstandard cfsetspeed on glibc accepts actual numbers, and applies them to both input and output. The standard cfset[io]speed functions only accept the symbolic B constants. And... they seem to be storing symbolic B constants in the c_[io]speed members, which seems wrong. >_< > Of course it might be useful to look at what applications expect to be > able to do. Thus, applications using the glibc API here need BOTHER to be defined and need to directly access c_[io]speed members. This seems like an ugly leak of implementation details, but I'm not sure whether it would be useful to have API-incompatible support for custom bauds. Maybe we should check what the BSDs or any other implementations do here... Rich