stty: support any baud on Linux, replace nix with rustix

[oech3]

• Closes stty: support arbitrary baudrate (at least on linux) as GNU coreutils 9.8 #8719 . rustix manages baud rate by u32 on all platforms. But OS itself should support any baud to actually use any baud. This PR adds support for any baud on Linux kernel (since bsd was already supported at nix crate).
• Closes stty: support B460800 and B921600 baud rates #14989 too since rustix has u32 -> enum decoder.

[codspeed]

Merging this PR will degrade performance by 24.56%

⚠️ 120 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

• sort_unique_utf8_locale
• du_wide_tree[(5000, 500)]
• dd_copy_64k_blocks
• cksum_raw_output
• du_deep_tree[(100, 3)]
• cksum_sysv
• cksum_default
• cksum_multiple_files
• cksum_crc
• sort_long_common_prefix_utf8_locale
• …and 110 more

ℹ️ 1 benchmark has no flame graph

The flamegraph could not be generated because too much time was spent in runtime internals, making the visualization not useful for performance analysis.

• sort_dictionary_order[500000]

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
❌ 2 regressed benchmarks
✅ 398 untouched benchmarks
⏩ 70 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	factor_three_39_bit_primes	593.6 ms	1,494.2 ms	-60.27%
❌	Simulation	factor_thirteen_39_bit_primes	8.8 s	9.3 s	-4.88%
⚡	Simulation	factor_five_38_bit_primes	1.9 s	1.7 s	+13.62%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing oech3:stty-unsafe (7e3e80e) with main (2e28cc3)²}

Footnotes

1. 70 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (f286c98) during the generation of this report, so 2e28cc3 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[github-actions]

GNU testsuite comparison:

Note: The gnu test tests/stty/bad-speed is now being skipped but was previously passing.

[xtqqczze]

Would it be possible to separate the refactor replacing nix with rustix from the fix for #8719 into separate PRs?

[oech3]

It is very difficult since rustix automatically supports any baud and nix and rustix cannot be mixed.

[xtqqczze]

What happens on Linux when arbitrary baud rates are not supported (i.e. with glibc < 2.42)? Do we panic, return an error, or fall back to a different behavior?

[oech3]

This should work for all libcs since this does not use glibc's API and uses ioctl directly. But I don't have legacy glibc.
I'm not sure if stty 51 test works on the CI. Currently, most stty tests are skipped due to missing console.

[xtqqczze]

This should work for all libcs since this does not use glibc's API and uses ioctl directly.

We have downstream consumers using rustix/use-libc cfg, so stty uses the glibc API in that case?

[oech3]

No. We still don't use same C-function with GNU which cause panic at nix.

[oech3]

nix (thus libc) creates a struct using cfset*speed (missing support for any baud on legacy glibc) at user space RAM and passes it to ioctl.
rustix creates a struct by its own way and passes it to ioctl.

[oech3]

On Ubuntu 24.04 runner (legacy glibc), I got

Run script -q -c "stty; echo '---'; stty 51; echo '---'; stty" /dev/null
speed 38400 baud;
line = 0;
-brkint
ixon
-imaxbel
---
---
speed 51 baud;
line = 0;
-brkint
ixon
-imaxbel

[xtqqczze]

I think I understand now: in Rustix tcgetattr, tcgetwinsize, tcsetattr, tcsetwinsize are implemented using syscalls rather than libc, even when the use_libc feature is enabled?

[oech3]

use_libc uses C-ioctl wrapper. So we bypasses cfset*speed which caused panic. (Thus, stty 51 worked under scripts).

[oech3]

So use_libc allows us LD_PRELOADing C-ioctl. But patching bad-speed.sh to intercept it changes meaning.