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: <1156424610.3012.29.camel@pmac.infradead.org>
Date:	Thu, 24 Aug 2006 14:03:30 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Stuart MacDonald <stuartm@...necttech.com>,
	'LKML' <linux-kernel@...r.kernel.org>,
	linux-serial@...r.kernel.org
Subject: RE: Serial custom speed deprecated?

On Thu, 2006-08-24 at 14:19 +0100, Alan Cox wrote:
> Actually to do this right we have to make a decision or two
> 
> The POSIX way of handling this requires the speeds are in the termios
> structure "somewhere". We can't easily implement cfgetispeed/cfgetospeed
> unless we grow the termios structure in the kernel and issue 3 new
> ioctls (keeping the others as trivial translations) and then bumping
> glibc and the kernel to do the right thing.
> 
> The alternative is that we provide an extra pair of speed ioctls and
> glibc does the magic to hide this lot while providing a termios with the
> new fields itself.
> 
> Whichever way we go glibc already has the fields present and the
> libc<->application API appears to be unchanged by this.
> 
> I'd rather we went the way of extending our termios to include c_ispeed,
> c_ospeed values. The code isn't hard for the remapping of the old ones
> and it avoids extra ioctls and the corner case races between two speed
> sets that occur if they are two ioctls.

Agreed. Some architectures have c_[io]speed in their struct termios
already, in fact, but others would need new ioctls for it.

-- 
dwmw2

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ