linux-kernel - Heads Up: Next Batch Of Serial/TTY Changes

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-next>] [day] [month] [year] [list]

Message-ID: <20070831221105.2fce9023@the-village.bc.nu>
Date:	Fri, 31 Aug 2007 22:11:05 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Heads Up: Next Batch Of Serial/TTY Changes

Firstly some architecture maintainers still haven't updated their
platform for arbitary tty speeds. The kernel is going to start whining
and issuing warnings on your platform if you don't keep up with the
programme (its been 6 months).

Secondly a lot of driver level code for termios methods is very very wrong
indeed. I've been trawling through and fixing the USB stuff in part but
some of it will need maintainer attention once the next changes go in.

- The termios interface says that you hand back the actual mode you set.
This means that if your driver sets a different speed, can't do the
selected parity etc you *MUST* update the passed tty->termios to reflect
your hardware. Mostly this seems to be the lack of support for mark/space
parity but if you've got a very limited specialist device you may need to
write a lot more (indeed the empeg effectively writes the entire termios)

- If your hardware has no termios features don't provide a dummy handler
just don't provide one. In that case the kernel will (as of updates) do
the right thing and preserve the previous speed and other hardware
parameters while updating the software ones.

- We now support seperate input and output speeds. Hardware that does
this wants updating accordingly

- If your hardware is initializing termios structures or copying and
editing them itself it is responsible for encoding c_ispeed/c_ospeed.
Right now there are some hacks to do it for you if you forget in most
cases, they will go away.

- The new code will add two types of helper to deal with the more horrible
bits of all this

	tty_encode_baud_rate(tty, inputbaud, outputbaud)
	tty_termios_encode_baudrate(termios, inputbaud, outputbaud)

and also

	tty_termios_copy_hw(new, old)

which will copy all the hardware implemented bits and speed from old to
new, which may be useful if your hardware needs to copy the old state
over and implements very little.

The speed encoding routines know about Bfoo encoding, arbitary rates and
also provide error tolerances so that programs using the Bfoo style speed
setup generally get Bfoo not BOTHER responses. Please don't put hacks for
this in drivers - if a case breaks then let me know and I'll fix the
encoder centrally.

Once all this is in the kernel will then acquire correct POSIX semantics
and error the ioctl if no requested change can be made.

Next stop after that is likely to be the open/close/hangup path.

Alan
-
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/