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