From: "Dora, Sunil Kumar" <SunilKumar.Dora@windriver.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>,
Kevin Buettner <kevinb@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"simon.marchi@efficios.com" <simon.marchi@efficios.com>,
"tromey@sourceware.org" <tromey@sourceware.org>,
"Kokkonda, Sundeep" <Sundeep.Kokkonda@windriver.com>
Subject: Re: [PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates
Date: Fri, 13 Feb 2026 21:21:52 +0000 [thread overview]
Message-ID: <DS0PR11MB79014E5252E28B1635DB147DE061A@DS0PR11MB7901.namprd11.prod.outlook.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2602131814260.2574@angie.orcam.me.uk>
[-- Attachment #1: Type: text/plain, Size: 3255 bytes --]
Hi Kevin, hi Maciej,
Thank you both for the feedback.
Kevin — I agree that using _HAVE_STRUCT_TERMIOS_* macros is not appropriate, since those are glibc-internal
definitions and not part of a public interface.
I will drop that approach and replace it with proper configure-time feature detection.
Maciej — Thank you for the suggestion regarding detection of arbitrary baud rate support.
Checking whether the Bxxx macros expand to their numeric baud rate equivalents is a very
clean way to determine whether cfsetospeed/cfsetispeed accept arbitrary speeds.
I will try this approach in configure to detect support.
I’ll rework the patch accordingly to:
- Use autoconf to detect arbitrary-speed support for cfset*
- Prefer the POSIX interface when available
- Fall back to the termios2 (BOTHER) interface when necessary
- Avoid relying on libc-internal definitions
I will send a v2 shortly. Thanks again for the review.
Best regards,
Sunil
________________________________
From: Maciej W. Rozycki <macro@orcam.me.uk>
Sent: Saturday, February 14, 2026 12:28 AM
To: Kevin Buettner <kevinb@redhat.com>
Cc: Dora, Sunil Kumar <SunilKumar.Dora@windriver.com>; gdb-patches@sourceware.org <gdb-patches@sourceware.org>; simon.marchi@efficios.com <simon.marchi@efficios.com>; tromey@sourceware.org <tromey@sourceware.org>; Kokkonda, Sundeep <Sundeep.Kokkonda@windriver.com>
Subject: Re: [PATCH] gdb/ser-unix: avoid musl build failure when setting custom baud rates
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Fri, 13 Feb 2026, Kevin Buettner wrote:
> 2) I don't think that it's correct to call cfsetospeed and cfsetispeed
> with arbitrary baud rates. According to the man page, these
> functions expect to be passed one of the "B" constants like B1200,
> B9600, etc, not arbitrary speeds. The existing code which uses the
> BOTHER extension is the correct way to do this.
FYI as from v2.42 glibc finally does support arbitrary baud rates with
`cfsetospeed' and `cfsetispeed' with Linux as well, in addition to Hurd,
which it has been since forever. This is fully documented in the glibc
manual; the man page you refer to is likely outdated.
The BOTHER flag is the raw OS kernel interface and its direct use is
discouraged.
Cf.
<https://inbox.sourceware.org/libc-alpha/20250612013546.1524096-1-hpa@zytor.com/>,
<https://sourceware.org/bugzilla/show_bug.cgi?id=10339>,
<https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5f138519ebdf88e1fc5395d65df0b780dd07829a>.
The position of the POSIX committee WRT the API is quoted there.
You can use autoconf to determine whether arbitrary baud rates are
supported, by checking if one of the Bxxx macros expands to its numeric
baud rate equivalent (you can check a couple if you feel pedantic).
With older versions of glibc and possibly other C library
implementations Bxxx macros have to be used of course and the choice of
baud rates available this way is limited. Resorting to using the BOTHER
flag might be the best approach, but the POSIX interface seems like the
best first choice.
Maciej
[-- Attachment #2: Type: text/html, Size: 7525 bytes --]
prev parent reply other threads:[~2026-02-13 21:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 15:21 sunilkumar.dora
2026-02-13 18:08 ` Kevin Buettner
2026-02-13 18:58 ` Maciej W. Rozycki
2026-02-13 21:21 ` Dora, Sunil Kumar [this message]
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=DS0PR11MB79014E5252E28B1635DB147DE061A@DS0PR11MB7901.namprd11.prod.outlook.com \
--to=sunilkumar.dora@windriver.com \
--cc=Sundeep.Kokkonda@windriver.com \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@redhat.com \
--cc=macro@orcam.me.uk \
--cc=simon.marchi@efficios.com \
--cc=tromey@sourceware.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox