Hi Kevin,

On 3/9/2026 6:55 AM, Kevin Buettner wrote:

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.

Hi Sunil,

On Sun, 22 Feb 2026 12:06:48 -0800
sunilkumar.dora@windriver.com wrote:

From: Sunil Dora <sunilkumar.dora@windriver.com>

The Linux custom baud rate implementation accessed the struct termios
members c_ispeed and c_ospeed directly. These fields are provided by
glibc but are not exposed by musl, which causes the build to fail on
musl-based systems.

Adjust set_custom_baudrate_linux to use a capability-based approach.
The Autoconf check HAVE_NUMERIC_BAUD_RATES determines whether
B-constants match numeric baud rates. If they do, use the standard
POSIX cfsetispeed and cfsetospeed interfaces. Otherwise, fall back
to the Linux-specific termios2 interface (TCGETS2) to support
arbitrary baud rates.

This preserves existing behavior on glibc systems while restoring
build compatibility with musl.

Here are my concerns:

1) The name HAVE_NUMERIC_BAUD_RATES doesn't really describe the
   feature that we wish to test for.  I think it should convey
   the fact that the implementations of cfsetospeed/cfsetispeed
   available on the platform are capable of accepting (and correctly
   using) arbitrary baud rate values.  Potential names include
   HAVE_CFSETSPEED_ARBITRARY and HAVE_ARBITRARY_BAUD_CFSETSPEED.
   (But if you have some other sensible preference, that's fine
   too.)

Thanks for pointing that out. I will rename the Autoconf check to HAVE_CFSETSPEED_ARBITRARY
in the next version.


2) I don't think that the final perror_with_name() call is correct.
   (I.e.  the one after the #else.) perror_with_name() should be used
   to print out an error message after calling a function associated
   with some underlying syscall.  But in this instance, there is no
   call - I think you ought to just be using a call to error().

You're right. I will replace perror_with_name() with a regular error() call.


3) I'd like to better understand what we might be losing by
   eliminating the fallback to TCGETS.

While looking into this, I noticed that on some architectures such as PowerPC and Alpha, the normal
struct termios (not termios2) actually has c_ispeed and c_ospeed fields. Because of this,
those systems might still support custom baud rates using the older TCGETS interface.

The build failure on musl happens because musl follows strict POSIX, and its struct termios does not
include these members (`c_ispeed` and `c_ospeed`) on any architecture.

To handle both cases, would it make sense to keep the TCGETS fallback but guard it with a feature check like
AC_CHECK_MEMBERS([struct termios.c_ospeed])?

That way we can still support the legacy behavior on glibc systems, while avoiding build issues on musl
where those fields don't exist.

This would result in something like the following compile-time paths:
----
#if defined(HAVE_CFSETSPEED_ARBITRARY)
/* Use cfsetispeed()/cfsetospeed() */

#elif defined(TCGETS2)
/* Use Linux termios2 interface with BOTHER */

#elif defined(HAVE_STRUCT_TERMIOS_C_OSPEED) && defined(BOTHER)
/* Legacy fallback using TCGETS/TCSETS */

#else
/* Custom baud rates not supported */
#endif

I’m thinking this might be a reasonable approach, but please let me know if I’m missing something.


4) You might change the commit title to something along the lines
   of "Modernize custom baudrate handling" or some such. This patch
   does much more than narrowly fixing the MUSL build failure.

Yes, that makes sense. I will update the commit title in the next version.


Kevin