Re: Serial custom speed deprecated?

[linux]

> Or we could just add a standardised extra set of speed ioctls, but then
> we need to decide what occurs if I set the speed and then issue a
> termios call - does it override or not.

Actually, we're not QUITE out of bits.  CBAUDEX | B0 is not taken.
That would make a reasonable encoding for a custom speed.
(But I haven't checked glibc... ah, yes, it should work!
See glibc-2.4/sysdeps/unix/sysv/linux/speed.c; browse at
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/?cvsroot=glibc
if you don't have a local copy source handy.)

What I'd do is, when converting to the old-style for tcgetattr, if the
current baud rate is not representable, cache it somewhere and return that
(or some other magic value).  If a tcsetatt call comes in that specifies
that magic value, use the cached baud rate.

If you make the cache just the current baud rate setting (the magic
value on set means "don't alter"), that will handle a lot of programs
that just want to play with handshaking.

If you make the cache separate, you can also survive an
old-interface-using program switching to a different baud rate and then
switching back.


Also note that if you truly want to support all baud rates in historical
use, you'll need to include at least one fractional bit for 134.5 baud.
(Unless you're sure that IBM 2741 terminals are truly dead. :-))

Alternatively, you could observe that asynchronous communications only
requires agreement withing 5% between sender and receiver, so specifying
a baud rate to much better than 1% is not too important.

Half-precision floating point would be ideal for the job. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/