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]

Message-Id: <1156459387.3007.218.camel@localhost.localdomain>
Date:	Thu, 24 Aug 2006 23:43:07 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Krzysztof Halasa <khc@...waw.pl>
Cc:	linux-serial@...r.kernel.org,
	"'LKML'" <linux-kernel@...r.kernel.org>,
	libc-alpha@...rces.redhat.com
Subject: Re: Serial custom speed deprecated?

Ar Iau, 2006-08-24 am 20:51 +0200, ysgrifennodd Krzysztof Halasa:
> Hmm... I'm not sure if I understand this correctly. Can't we just
> create the 3 new ioctls in the kernel and teach glibc to use it?

We could implement an entirely new TCSETS/TCGETS/TCSETSA/SAW which used
different B* values so B9600 was 9600 etc and the data was stored in
c_ospeed/c_ispeed type separate fields and we'd support arbitary speeds
for input and output once and for all, shoot all the multiplier hacks
etc. As it happens the kernel code for this is easy owing to some
fortuitous good design long ago in the tty layer.

We could also implement a Linux "improved" TCSET* new set of ioctls that
had sensible speed fields, utf-8 characters for the _cc[] array and new
flags for all the utf-8 handling and the like. That would be less
compatible though.

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.

> The old ioctls would be optional in the kernel (and perhaps in glibc,
> sometime).

The kernel side translation is thankfully really trivial.

> Not sure if we want int, uint, or long long for speed values :-)

You want speed_t according to POSIX.

I've no idea what the glibc impact of this kind of thing would be
(consider new glibc, old kernel etc).  I've cc'd the libc folks but I am
not sure it is practical to do.

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/