Call flock(fd, LOCK_UN) explicitly for managed file at term_exitfunc().
This should, normally, not be necessary. Normally, exiting the program
should take care of unlocking the file. Unfortuntelly, it has been
observed that, on some systems, exiting or closing an flock(2)'ed tty fd
has peculiar side effects (like not reseting the modem-control lines,
even if HUPCL is set).
Set the levels of DTR and RTS modem-control lines (according to the
--lower/raise-dtr/rts command-line options) *twice*: Once
immediatelly (as quickly as possible) after opening the port (before
actually configuring it), and once after configuring it. On some systems
configuring the port (i.e. calling tcsetattr) has the effect of reseting
the DTR and RTS signals.
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
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, NetBSD, 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.
- Made functions term_[raise/lower]_dtr() work *only* by using the
respective ioctl, not by setting the baudrate to 0. In case the ioctl
is not supported for a system, the functions fail. Function
term_pulse_dtr() still works by setting the baudrate to zero, if the
ioctl is not supported. As a result, for systems without support for
ioctls that set / clear the modem-control lines, DTR can only be
pulsed, not toggled.
- When using tcsetattr() to pulse the DTR line (i.e. on systems where
ioctls for setting / clearing the modem control lines are not
supported), set only the output speed to B0, not both input and output
speed.
