Expand description
An interface for controlling asynchronous communication ports
This interface provides a safe wrapper around the termios subsystem defined by POSIX. The underlying types are all implemented in libc for most platforms and either wrapped in safer types here or exported directly.
If you are unfamiliar with the termios API, you should first read the
API documentation and
then come back to understand how nix safely wraps it.
It should be noted that this API incurs some runtime overhead above the base libc definitions.
As this interface is not used with high-bandwidth information, this should be fine in most
cases. The primary cost when using this API is that the Termios datatype here duplicates the
standard fields of the underlying termios struct and uses safe type wrappers for those fields.
This means that when crossing the FFI interface to the underlying C library, data is first
copied into the underlying termios struct, then the operation is done, and the data is copied
back (with additional sanity checking) into the safe wrapper types. The termios struct is
relatively small across all platforms (on the order of 32-64 bytes).
The following examples highlight some of the API use cases such that users coming from using C or reading the standard documentation will understand how to use the safe API exposed here.
Example disabling processing of the end-of-file control character:
termios.control_chars[VEOF as usize] = _POSIX_VDISABLE;The flags within Termios are defined as bitfields using the bitflags crate. This provides
an interface for working with bitfields that is similar to working with the raw unsigned
integer types but offers type safety because of the internal checking that values will always
be a valid combination of the defined flags.
An example showing some of the basic operations for interacting with the control flags:
termios.control_flags & ControlFlags::CSIZE == ControlFlags::CS5;
termios.control_flags |= ControlFlags::CS5;Baud rates
This API is not consistent across platforms when it comes to BaudRate: Android and Linux both
only support the rates specified by the BaudRate enum through their termios API while the BSDs
support arbitrary baud rates as the values of the BaudRate enum constants are the same integer
value of the constant (B9600 == 9600). Therefore the nix::termios API uses the following
conventions:
cfgetispeed()- Returnsu32on BSDs,BaudRateon Android/Linuxcfgetospeed()- Returnsu32on BSDs,BaudRateon Android/Linuxcfsetispeed()- Takesu32orBaudRateon BSDs,BaudRateon Android/Linuxcfsetospeed()- Takesu32orBaudRateon BSDs,BaudRateon Android/Linuxcfsetspeed()- Takesu32orBaudRateon BSDs,BaudRateon Android/Linux
The most common use case of specifying a baud rate using the enum will work the same across platforms:
cfsetispeed(&mut t, BaudRate::B9600);
cfsetospeed(&mut t, BaudRate::B9600);
cfsetspeed(&mut t, BaudRate::B9600);Additionally round-tripping baud rates is consistent across platforms:
let speed = cfgetispeed(&t);
assert!(speed == cfgetospeed(&t));
cfsetispeed(&mut t, speed);On non-BSDs, cfgetispeed() and cfgetospeed() both return a BaudRate:
assert!(cfgetispeed(&t) == BaudRate::B9600);
assert!(cfgetospeed(&t) == BaudRate::B9600);But on the BSDs, cfgetispeed() and cfgetospeed() both return u32s:
assert!(cfgetispeed(&t) == 9600u32);
assert!(cfgetospeed(&t) == 9600u32);It’s trivial to convert from a BaudRate to a u32 on BSDs:
assert!(cfgetispeed(&t) == BaudRate::B9600.into());
assert!(u32::from(BaudRate::B9600) == 9600u32);And on BSDs you can specify arbitrary baud rates (note this depends on hardware support)
by specifying baud rates directly using u32s:
cfsetispeed(&mut t, 9600u32);
cfsetospeed(&mut t, 9600u32);
cfsetspeed(&mut t, 9600u32);Structs
Enums
termios.c_cc array for special characters.