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? 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 >