Sunil Kumar Dora writes: > On 3/27/2026 11:45 PM, 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. > > On Tue, 24 Mar 2026 09:45:25 -0700 > sunilkumar.dora@windriver.com wrote: > > From: Sunil Dora > > On musl-based systems exposes BOTHER, so the > Linux-specific custom baud rate path was being compiled. However, > musl's struct termios does not provide the public members c_ispeed > and c_ospeed, causing a build failure. > > This series fixes the build issue at the macro level (patch 1). > It then adds the preferred POSIX cfsetispeed/cfsetospeed path as the > first choice on platforms where the host libc supports arbitrary baud > rates, such as glibc 2.42 and later, GNU Hurd, and potentially other > libc implementations (patch 2). The existing Linux (termios2/BOTHER) > and Darwin (IOSSIOSPEED) paths remain as fallbacks. > > The two patches are independent: > - Patch 1 is a pure build fix with no functional change. > - Patch 2 adds the new POSIX feature on top of the fixed guard. > > set_custom_baudrate_linux is left unchanged. > > Changes since V4: > - Split into two patches, with patch 1 as a pure build fix > and patch 2 adding the POSIX interface. > - Fixed #if guard formatting and added full stop to the > AC_DEFINE description. > - Removed parentheses from function name references in > commit messages and comments. > - Updated NEWS entry to describe which configurations are > affected. > > v4: https://sourceware.org/pipermail/gdb-patches/2026-March/226133.html > v3: https://sourceware.org/pipermail/gdb-patches/2026-March/225952.html > v2: https://sourceware.org/pipermail/gdb-patches/2026-February/225251.html > v1: https://sourceware.org/pipermail/gdb-patches/2026-February/224968.html > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33747 > > > Both parts are approved. Thanks for persevering through the many > requests for changes. > > One thing I noticed - Some error messages in ser-unix.c still use > "Can not" whereas you uniformly (and correctly IMO) use "Cannot". > If you're up for doing a follow-on patch, one which does > s/Can not/Cannot/ on the remaining occurrences would be appreciated. > > Approved-by: Kevin Buettner > > Hi Kevin, > > I just wanted to check in since I don't have commit access. When you have a moment, could you please push the two > patches? I'll push them on your behalf now. > > Also, I'm happy to send a follow-on patch to address the remaining "Can not" -> "Cannot" occurrences in ser-unix.c. > > Thanks, > Sunil Dora