[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.
On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
> [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?
Just my two cents, maybe we can conclude that for now we don't care
thus don't implement anything, but that everything you identified as
a possible place to steal bits should be marked "reserved for future
use, must be sent as zero". This will leave you ample room later to
decide how to proceed (and maybe it will not be the bps that you'll
want to change but the number of lanes, or word size, or bit encoding,
especially at 4 Gbps).
Regards,
Willy
On 10/09/18 12:51, Willy Tarreau wrote:
> On Tue, Oct 09, 2018 at 12:19:04PM -0700, H. Peter Anvin wrote:
>> [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?
>
> Just my two cents, maybe we can conclude that for now we don't care
> thus don't implement anything, but that everything you identified as
> a possible place to steal bits should be marked "reserved for future
> use, must be sent as zero". This will leave you ample room later to
> decide how to proceed (and maybe it will not be the bps that you'll
> want to change but the number of lanes, or word size, or bit encoding,
> especially at 4 Gbps).
>
Well, it would be nice to be able to pre-enable it in glibc as much as
possible. What I'm thinking of doing is to use a 64-bit "baud_t" type
in glibc, and reserve the upper 4 bits of the speed field as must be
zero (which is de facto the case anyway.) In other to avoid a *huge*
user space ABI versioning mess we need to be able to encode the baud
rate inside a 32-bit speed_t in glibc, and given that I believe it would
be a Very Nice Thing if we could squeeze the information into 32 bits on
the kernel side as well.
So reserving the upper 4 bits I think is The Right Thing. I think that
is actually a null change.
I'm not sure if it would be a good idea to make the kernel -EINVAL on
currently-unused c_cc bytes or c_*flags; I can see pros and cons (the
latter being in no small part that that is not legacy behavior.)
-hpa
On Tue, 9 Oct 2018 12:19:04 -0700
"H. Peter Anvin" <[email protected]> wrote:
> [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.
Even RS485 at 4MBits involves deep magic. I think we are fairly safe. Not
only that but our entire tty layer isn't capable of sustaining anything
even remotely in that range.
I think its non issue.
Alan
On October 10, 2018 1:17:17 PM PDT, Alan Cox <[email protected]> wrote:
>On Tue, 9 Oct 2018 12:19:04 -0700
>"H. Peter Anvin" <[email protected]> wrote:
>
>> [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.
>
>Even RS485 at 4MBits involves deep magic. I think we are fairly safe.
>Not
>only that but our entire tty layer isn't capable of sustaining anything
>even remotely in that range.
>
>I think its non issue.
>
>Alan
I'm mostly wondering if it is worth future-proofing for new transports. It sounds like we can have a consensus on leaving the upper 4 bits of the speed fields reserved, but leave the details of implementation for the future?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
> I'm mostly wondering if it is worth future-proofing for new transports. It sounds like we can have a consensus on leaving the upper 4 bits of the speed fields reserved, but leave the details of implementation for the future?
It seems reasonable, although I think the reality is that any future
transport is not going to be a true serial link, but some kind of serial
emulation layer. For those the speed really only matters to tell editors
and the like not to bother being clever.
I mean - what is the baud rate of a pty ?
Alan
On October 11, 2018 5:31:34 AM PDT, Alan Cox <[email protected]> wrote:
>> I'm mostly wondering if it is worth future-proofing for new
>transports. It sounds like we can have a consensus on leaving the upper
>4 bits of the speed fields reserved, but leave the details of
>implementation for the future?
>
>It seems reasonable, although I think the reality is that any future
>transport is not going to be a true serial link, but some kind of
>serial
>emulation layer. For those the speed really only matters to tell
>editors
>and the like not to bother being clever.
>
>I mean - what is the baud rate of a pty ?
>
>Alan
Whatever the master wants it to be...
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 10/11/18 12:36 PM, Craig Milo Rogers wrote:
> On 18.10.11, Alan Cox wrote:
>> I mean - what is the baud rate of a pty ?
>
> Solaris made the distinction between B0, which means pty hangup mode,
> and any other baud rate:
>
> https://docs.oracle.com/cd/E88353_01/html/E37851/pty-4d.html
>
> But... why not implement a pty bandwidth limitation layer? You say, I
> need to justify it? It's for, uh... protecting the system from unrestricted
> pty usage DOS attacks! Yeah. That's what it's for.
B0 is hangup, that's not in question.
-hpa
On 18.10.11, Alan Cox wrote:
> I mean - what is the baud rate of a pty ?
Solaris made the distinction between B0, which means pty hangup mode,
and any other baud rate:
https://docs.oracle.com/cd/E88353_01/html/E37851/pty-4d.html
But... why not implement a pty bandwidth limitation layer? You say, I
need to justify it? It's for, uh... protecting the system from unrestricted
pty usage DOS attacks! Yeah. That's what it's for.
Craig Milo Rogers
On Thu, Oct 11, 2018 at 07:14:30AM -0700, [email protected] wrote:
> >
> >I mean - what is the baud rate of a pty ?
>
> Whatever the master wants it to be...
I think Alan's point is that it is highly unlikely you would be able
to push the equivalent of 4 gbps through a PTY layer. The TTY later
was never engineered for those speeds, and the real question is ---
what's the point? That's what Ethernet is for.
- Ted
On 10/11/18 2:40 PM, Theodore Y. Ts'o wrote:
> On Thu, Oct 11, 2018 at 07:14:30AM -0700, [email protected] wrote:
>>>
>>> I mean - what is the baud rate of a pty ?
>>
>> Whatever the master wants it to be...
>
> I think Alan's point is that it is highly unlikely you would be able
> to push the equivalent of 4 gbps through a PTY layer. The TTY later
> was never engineered for those speeds, and the real question is ---
> what's the point? That's what Ethernet is for.
>
I like to consider the far future; I think things like the Y2038 problem is a
good example. Or, as I like to put it, "numbers are cheap, running out of
numbers is expensive." Sounds like we have enough of a plan that we aren't
completely stuck should it ever become an issue. It might never, of course.
-hpa