linux-kernel - Re: Serial custom speed deprecated?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Aug 2006 08:17:39 -0400
From:	"linux-os \(Dick Johnson\)" <linux-os@...logic.com>
To:	<linux@...izon.com>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: Serial custom speed deprecated?

On Sat, 26 Aug 2006 linux@...izon.com wrote:

>> 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.

B0 is not a bit (there are no bits in 0). It won't work.

> 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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
..

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@...logic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/