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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 28 Aug 2006 21:09:18 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Stuart MacDonald <stuartm@...necttech.com>
Cc:	'Rogier Wolff' <R.E.Wolff@...Wizard.nl>,
	'Alan Cox' <alan@...rguk.ukuu.org.uk>,
	"'linux-os (Dick Johnson)'" <linux-os@...logic.com>,
	'Krzysztof Halasa' <khc@...waw.pl>,
	'David Woodhouse' <dwmw2@...radead.org>,
	linux-serial@...r.kernel.org, 'LKML' <linux-kernel@...r.kernel.org>
Subject: Re: Serial custom speed deprecated?

On Mon, Aug 28, 2006 at 10:14:30AM -0400, Stuart MacDonald wrote:
> From: On Behalf Of Rogier Wolff
> > Note that IMHO, we should have started hiding this mess from /drivers/
> > a long time ago. The tty layer should convert the B_9600 thingies to
> > "9600", the integer, and then call the set_termios function. The
> > driver should be prohibited from looking at how the the baud rate came
> > to be 9600, and attempt to approach the requested baud rate as good as
> > possible. It might return a flag somewhere: Not exact. In the example
> > above, the resulting baud rate is about 1.4 baud off: 9598.6. This is
> > not a problem in very many cases.
> > 
> > Once this is in place, you lose a lot of "figure out the baud rate
> > integer from the B_xxx settings" code in all the drivers, as well as
> > that we get to provide a new interface to userspace without having to
> > change ALL drivers at the same time. This decouples the drivers from
> > the kernel<->userspace interface.
> 
> I'll second the motion. :-)

You might do, but it's incompatible with the POSIX standard.  As I
explained to Rogier (he took it off list) there's no need for "inexact"
flags.

If we pass a baud rate via tcsetattr() (or ioctl), you should set what
ever settings you can.  If you can set _no_ settings, you return an
error.  If you can set at least one setting, you do not return an error,
and you only set those settings you can do.

When you subsequently read the settings via tcgetattr(), POSIX requires
that the returned information be what the port is _actually_ doing.

So, this means that if you can only do 9599 baud and not 9600 baud,
maybe you should be returning 9599 baud.

On the same subject, if you don't support RTS/CTS flow control, and
userland requests CRTSCTS, you shouldn't be allowing CRTSCTS to be set.
And indeed, if you don't allow that in the kernel today, stty will
correctly issue a warning that it was "unable to perform all requested
operations".

So, while I whole heartedly agree with passing baud rates numerically,
I do not think we need any of this inexact flagging nonsense provided
we implement something as userland programs expect - iow, the POSIX
behaviour.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/