[PATCH RFC v2 0/8] termios: support arbitrary baud rates on Linux, minor cleanups, proposed alternative interface

[H. Peter Anvin]

[Sorry for the resend; apparently I can't spell.]

Here is another RFC for the arbitrary baud rates on Linux patchset,
this time on top of the <termio.h> removal patch.

It also includes some generic cleanups to the best of my ability.

Finally, the tail end of this series also adds a proposed interface
for future standardization, per the POSIX committee request:

 [https://www.austingroupbugs.net/view.php?id=1916#c7135]

	A future version of this standard is expected to add at least
	the following symbolic constants for use as values of objects
	of type speed_t: B57600, B115200, B230400, B460800, and
	B921600.

	Implementations are encouraged to propose additional
	interfaces which will make it possible to set and query a
	wider range of speeds than just those enumerated by the
	constants beginning with B. If a set of common interfaces
	emerges between several implementations, a future version of
	this standard will likely add those interfaces.


The parts I really could use help with review:

1. Some of my patches touch common code; as far as I can tell the
   common code is simply broken (see the note on cfsetspeed() below.)

  I don't really have the ability to test the non-Linux platforms that
   glibc supports (Hurd, BSD, any others?)


2. When to use __foo() functions. In my patches I have assumed that
   calls internal to glibc.so should be using __foo() not foo(), but I
   got a very muddy reply as to "when things cross namespace
   boundaries", pointing me to a document which brought absolutely no
   clarity to the issue.

   The current code is insanely inconsistent, using __tcgetattr() but
   tcsetattr(). The MIPS/SPARC workarounds more or less require a
   __tcsetattr(), even if Linux-local, but it seems to make no sense
   for such an inconsistency.

   Since all my changes are inside glibc.so I have been assuming that
   The Right Thing[TM] is to do what most other functions do and that
   glibc should internally use hidden __foo() and have weak aliases to
   foo() so that internal calls are always direct, but if that is
   incorrect I need either some clarification or corrections after
   review.


3. As a particular example of brokenness: the common implementation of
   cfsetspeed() for example, blindly assume a fixed set of baud rates,
   even if cfset[io]speed() has no such limitation.

   The generic cfsetspeed() really should let [__]cfsetospeed() handle
   allowing or disallowing the baud rate constant and then call
   __cfsetispeed() with either B0 or the same constant (I presume the
   latter is the desired behavior, but I'm not sure.)

   The current cfsetspeed() allows *either* B constants or a baud rate
   correspond to a B constant (but no others!), although I believe
   that with Linux converted, the only remaining case of Bxxx != xxx
   is Hurd with USE_OLD_TTY set, which I presume is by now a legacy
   configuration that few people care about (and in that case, that
   code should be moved into sysdeps/mach/hurd, and preferably into
   __cfset[io]speed() as well -- it makes zero sense to have
   cfsetspeed() behave differently than cfset[io]speed().

   This patchset fixes cfsetspeed() and removes USE_OLD_TTY support.


4. Why does __libc_tcdrain() have libc_hidden_proto() but not
   libc_hidden_def() (apparently at some point there was an exported
   __libc_tcdrain@@GLIBC_PRIVATE, but that seems to be long gone
   history. I assume the libc_hidden_proto() didn't exist back then,
   either.) However, things seem to break if I add it...

5. Why is __libc_tcdrain() called that and not __tcdrain()?



    -hpa