From: Krzysztof Halasa <khc@pm.waw.pl>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Woodhouse <dwmw2@infradead.org>,
Stuart MacDonald <stuartm@connecttech.com>,
linux-serial@vger.kernel.org,
'LKML' <linux-kernel@vger.kernel.org>
Subject: Re: Serial custom speed deprecated?
Date: Thu, 24 Aug 2006 20:51:12 +0200 [thread overview]
Message-ID: <m31wr6otlr.fsf@defiant.localdomain> (raw)
In-Reply-To: <1156441293.3007.184.camel@localhost.localdomain> (Alan Cox's message of "Thu, 24 Aug 2006 18:41:33 +0100")
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> Does that mean that standard things like termios will use:
>> #define B9600 9600
>> #define B19200 19200
>
> That would have been very smart when Linus did Linux 0.12, unfortunately
> he didn't and we've also got no spare bits. Worse still if we exported
> them that way glibc has now way to map new speeds onto the old ones for
> applications.
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?
The compatibility ioctls would talk to new ioctls only and translate
things. Anything (userspace) wanting non-traditional speeds would
have to use new interface (i.e., be compiled against the new glibc)
and the speeds would show as EXTA or EXTB or something when queried
using old ioctl.
Yes, the binary interface between glibc and userland would change
(with compatibility calls translated by glibc to new ioctls, or to
old ones on older kernels).
The old ioctls would be optional in the kernel (and perhaps in glibc,
sometime).
Not sure if we want int, uint, or long long for speed values :-)
--
Krzysztof Halasa
next prev parent reply other threads:[~2006-08-24 18:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <028a01c6c6fc$e792be90$294b82ce@stuartm>
[not found] ` <1156411101.3012.15.camel@pmac.infradead.org>
[not found] ` <m3bqqap09a.fsf@defiant.localdomain>
2006-08-24 17:41 ` Serial custom speed deprecated? Alan Cox
2006-08-24 18:51 ` Krzysztof Halasa [this message]
2006-08-24 20:43 ` linux-os (Dick Johnson)
2006-08-24 22:11 ` Alan Cox
2006-08-27 6:52 ` Rogier Wolff
2006-08-27 10:00 ` Russell King
2006-08-28 14:14 ` Stuart MacDonald
2006-08-28 20:09 ` Russell King
2006-08-29 6:20 ` Rogier Wolff
2006-08-29 7:46 ` Russell King
2006-08-25 15:17 ` Stuart MacDonald
2006-08-25 15:52 ` linux-os (Dick Johnson)
2006-08-24 22:43 ` Alan Cox
2006-08-25 10:58 ` Krzysztof Halasa
2006-08-25 15:21 ` Stuart MacDonald
2006-08-25 19:32 ` Russell King
2006-08-25 20:21 ` Stuart MacDonald
2006-08-25 20:54 ` linux-os (Dick Johnson)
2006-08-25 20:39 ` Theodore Tso
2006-08-26 12:16 ` Krzysztof Halasa
2006-08-25 15:10 ` Stuart MacDonald
2006-08-24 22:05 ` Russell King
2006-08-25 15:01 ` Stuart MacDonald
[not found] <033001c6c77a$a7d8ab10$294b82ce@stuartm>
2006-08-24 13:19 ` Alan Cox
2006-08-24 13:03 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m31wr6otlr.fsf@defiant.localdomain \
--to=khc@pm.waw.pl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=stuartm@connecttech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).