If picocom is compiled *with* custom-baudrate support (USE_CUSTOM_BAUD)
for Linux, then it uses a new set of ioctl's (TCGETS2 vs TCGETS, etc) to
access the serial ports. This patch allows the custom baudrate support
to be disabled at runtime (without recompiling), and picocom to switch
to using the old ioctl's.
To disable custom baudrate support (and switch back to the "old" ioctls)
simply define the environment variable NO_CUSTOM_BAUD, before starting
picocom.
This applies only to Linux and, obviously, only when picocom has been
compiled with custom baudrate support (USE_CUSTOM_BAUD).
Be very conservative when enabling custom baudrate
support (USE_CUSTOM_BAUD) by default. Only enable (by default) on
systems where we know it will cause no problems. For other systems the
user can try to enable it explicitly (see Makefile).
Currently enabled by default on:
Linux, Kernel verison > 2.6.0, x86 and x86_64 architectures
FreeBSD, OpenBSD, DragonFly BSD
For some systems (OSes, versions, architectures) custom-baudrate
support is enabled by default.
For others, support may work, but must be enabled by defining
USE_CUSTOM_BAUD in the Makefile
You can also disable custom baudrate support altogether (even for
systems where it's enabled by default), by defining NO_CUSTOM_BAUD in
the Makefile
Introduced `#define HAS_CUSTOM_BAUD` for platforms which have appropriate implementation.
Moving that `#if defined(__linux__) && defined(USE_CUSTOM_BAUD)` ... stuff out of `term.c`and put it to `termios2.h` / `custbaud_bsd.h` headers.
Moving that platform specific `#ifdefs` to the platform specific headers helps removing duplicate complex `#ifdef` constructs.
The both platform specific headers then do `#define HAS_CUSTOM_BAUD` to signal that custom baudrate support is implemented for the target platform.
I'd tested all above mentioned platforms with both USE_CUSTOM_BAUD unset and set to check if that refactoring don't raises unexpected issues.
