This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #24 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to hpa@zytor.com from comment #23)
> I hacked on the above, and the more I work on it, the more I'm unhappy with
> the *baud() functions.
> 
> The big problem that I see is that an existing application doing getxspeed()
> ... setxspeed() ought to have a reasonable expectation of returning to the
> original baud rate in all circumstances, so an interface which doesn't
> encode this information in speed_t is fundamentally broken.
> 
> So I came up with this idea:
> 
>     speed_t cfencspeed(baud_t)
>     baud_t cfdecspeed(speed_t)
> 
> ... keeping the interfaces using speed_t but having a system-independent way
> to encode and decode this abstract type into a true integer. This also
> becomes a trivial interface (null transformation) on systems which use
> speed_t == baud.

It is not clear to me on to encode the baud_t information on current termios
struct. Is the idea to reuse c_ispeed/c_ospeed fields? We might have some
freedom here since they are not POSIX, but since we set them on
cfsetospeed/cfsetispeed we will break this semantic if we reuse them.

> 
> On Linux, in order to support the existing Bxxx constants without
> modification, we can define the speed_t as a speed, *except* that the Bxxx
> constants and their corresponding integers are swapped.  In other words,
> B300 == 7, so 7 baud would be represented by the value 300.  Although
> slightly complicated, this encoding is 100% efficient, and has the important
> property of being alias-free, so that a direct comparison cannot have false
> negatives.
> 
> So far, so good.


> 
> Now, assuming we really want to support baud rates over 4 Gbps, I'm thinking
> of an interface which might amount to a 5:27 floating point number. no sign
> bit, and biased for integers only.  Baud rates below 2^27 ~ 134 Mbps would
> be encoded as "denormals"; above that the value will be encoded with an
> implicit one, which means that values below 2^28 ~ 268 Mps will still be
> identity-transformed with an integer (since 00001 ... would correspond to a
> shift of 0 but with an implicit 1, and the implicit 1 would fall into
> exactly the same bit position as the 1 in the exponent.)
> 
> This would be able to encode baud rates up to to ~288 Pbps with a maximum
> error of 4 ppb, without breaking the round-trip property of speed_t and
> without having to change the current termios structures (except for SPARC
> and possibly MIPS.)
> 
> Thoughts?

This might be an option, it should cover mostly operations. The only issue I
can see if/when kernel starts to support baud rates over 4 Gbps, will it follow
the same userland definition or will it use a termios3 struct with larger
c_*speed values? For latter how would it handle the cases where underlying
hardware supports a baud rate which is not representable in this 5:27 format,
would it return EINVAL or round the input?

Another option might be just extend the termios structure to use large values
for c_ispeed/c_ospeed and add a compatibility symbols for all architectures
(and no more sparc/mips issues).

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]