[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Apr 2024 13:29:56 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: 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
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.
