From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] making termios BOTHER speeds work
Date: Thu, 11 Apr 2024 13:29:56 -0400 [thread overview]
Message-ID: <20240411172956.GC4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <20240411165556.GB4163@brightrain.aerifal.cx>
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
next prev parent reply other threads:[~2024-04-11 17:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 14:24 Rich Felker
2024-04-11 16:55 ` Rich Felker
2024-04-11 17:29 ` Rich Felker [this message]
2024-04-11 17:55 ` Jeffrey Walton
2024-04-11 18:30 ` Markus Wichmann
2024-04-11 18:34 ` Raphael Kiefmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240411172956.GC4163@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).