[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 0.84%

1 warning, 1 note

⚠️ 123 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

ℹ️ 1 benchmark has no flamegraph

The flamegraph wasn't generated: most of the time was spent in runtime internals, which would leave nothing useful to analyze.

See affected benchmarks

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

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Memory	cp_recursive_deep_tree[(120, 4)]	532.6 KB	699.2 KB	-23.82%
⚡	CPU Simulation	true_consecutive_calls	350.2 ns	294.7 ns	+18.85%
⚡	Memory	du_deep_tree[(100, 3)]	82.4 KB	76.5 KB	+7.68%

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 (c6fc86b) with main (679d1f2)²}

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 (eb7d426) during the generation of this report, so 679d1f2 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:

Congrats! The gnu test tests/dd/nocache_fail is now passing!
Note: The gnu test tests/rm/rm-readdir-fail was skipped on 'main' but is now failing.

[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]

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.

[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.

[oech3]

hopefully last rebase against confliction

[oech3]

Unfortunately, we still need to map enum baud rates for stty --save at least on Linux. BSDs,Cygwin do not require enum.

[xtqqczze]

fuzz failures tracked by #15567.

[xtqqczze]

Switching to rustix has enabled support for AIX targets. Could you consider pushing a commit removing the cfg exclusion in this PR, or addressing it in a follow-up PR?

[oech3]

I cannot much care about minor targets. I'd like to keep diff minimal at here.

[xtqqczze]

There will be follow-up work in any case for OUTPUT_FLAGS target cfg's, so fine for now.

[oech3]

@sylvestre Would you consider merging this?