[Bug libc/10339] Terminal interface: non-standard baudrates are not handled properly on Linux-systems

["hpa at zytor dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=10339

--- Comment #21 from hpa at zytor dot com <hpa at zytor dot com> ---
That should have been "the inventiveness of programmers when it comes to
shooting themselves in the foot is boundless".

I would have been far more interested in avoiding a wart here if the glibc code
hadn't already promulgated a structure with non-functional speed fields on
almost every platform; if that had not been the case I would have strongly
considered defining a structure with __uint64_t for the __baud_t type, but at
this point it would mean versioning *ALL* architectures, and the cost seems to
massively exceed the value.

I suspect if we need to support speeds > 4 Gbps, we probably would augment the
kernel interface by leveraging spare bytes in c_cc; they are guaranteed to be
initialized to 0 by the kernel already, and unless I'm completely mistaken,
every Linux architecture defines at least 19 bytes in the kernel NCCS2, and
none uses more than 17, so we could define:

True xbaud = c_xspeed << c_cc[VxSPDSHL]

This would avoid requiring new kernel ioctls while retaining backwards
compatibility.

Which I guess begs the question if what we should do is define baud_t to be 64
bits for the function calls, returning EINVAL at this point, but leave the
fields in the *structure* (which user space isn't *supposed* to look at) as
unsigned int.

<joke> Maybe we should make it a double, since the above is actually a
floating-point format? </joke>

--- Comment #22 from hpa at zytor dot com <hpa at zytor dot com> ---
That should have been "the inventiveness of programmers when it comes to
shooting themselves in the foot is boundless".

I would have been far more interested in avoiding a wart here if the glibc code
hadn't already promulgated a structure with non-functional speed fields on
almost every platform; if that had not been the case I would have strongly
considered defining a structure with __uint64_t for the __baud_t type, but at
this point it would mean versioning *ALL* architectures, and the cost seems to
massively exceed the value.

I suspect if we need to support speeds > 4 Gbps, we probably would augment the
kernel interface by leveraging spare bytes in c_cc; they are guaranteed to be
initialized to 0 by the kernel already, and unless I'm completely mistaken,
every Linux architecture defines at least 19 bytes in the kernel NCCS2, and
none uses more than 17, so we could define:

True xbaud = c_xspeed << c_cc[VxSPDSHL]

This would avoid requiring new kernel ioctls while retaining backwards
compatibility.

Which I guess begs the question if what we should do is define baud_t to be 64
bits for the function calls, returning EINVAL at this point, but leave the
fields in the *structure* (which user space isn't *supposed* to look at) as
unsigned int.

<joke> Maybe we should make it a double, since the above is actually a
floating-point format? </joke>

-- 
You are receiving this mail because:
You are on the CC list for the bug.