[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3fcef1c1-d746-ae82-c0e6-f079b1a53ffb@zytor.com>
Date: Tue, 9 Oct 2018 12:19:04 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: linux-serial@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>, Johan Hovold <johan@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>
Subject: Insanely high baud rates
[Resending to a wider audience]
In trying to get the termios2 interface actually implemented in glibc,
the question came up if we will ever care about baud rates in excess of
4 Gbps, even in the relatively remote future.
If this is something we care about *at all*, I would like to suggest
that rather than defining yet another kernel interface, we steal some
bits from the MSB of the speed fields, alternatively one of the c_cc
bytes (all likearchitectures seem to have c_cc[18] free) or some field,
if we can find them, in c_cflags, to indicate an exponent.
With 5 bits from the top of the speed fields, the current values would
be identical up to 248 Gbps, and values up to ~288 Pbps would be
encodable ±2 ppb.
In the short term, all we would have to do in the kernel would be
erroring out on baud rates higher than 0x0fffffff (2^28-1 due to
implicit one aliasing rhe first bit of a 5-bit exponent – less than 2^27
are functionally denorms.) However, I'd like to put the glibc
infrastructure for this now if this is something we may ever be
interested in.
Thoughts?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists