Re: Serial custom speed deprecated?

Re: Serial custom speed deprecated?

[Alan Cox]

Ar Iau, 2006-08-24 am 18:27 +0200, ysgrifennodd Krzysztof Halasa:
> David Woodhouse <dwmw2@infradead.org> writes:
> 
> >> If custom speeds are deprecated, what's the new method for setting
> >> them? Specifically, how can the SPD_CUST functionality be accomplished
> >> without that flag? I've checked 2.5.64 and 2.6.17, and don't see how
> >> it is possible. 
> >
> > We need a way to set the baud rate as an _integer_ instead of the Bxxxx
> > flags.
> 
> 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.

The speed_t values in the termios struct are also Bfoo encoded so it
turns out don't help.

At this point I think we need

-	An ioctl to set/get the actual baud rate input/output
-	Some kind of termios flag to indicate they are being used (as we have
CBAUDEX now). [We could "borrow" the 4Mbit one and dual use it IMHO]

For drivers tty_get_baud_rate would return the actual speed as before.

We would need a driver ->set_speed method for the cases where
- ioctl is called to set specific board rate
- OR termios values for tty speed change
- While we are at it we might want to make ->set_termios also allowed to
fail

[and if you had no ->set_speed method non standard speeds would be
refused by the tty layer for back compat]

Anyone got any problems with this before I go and implement it ?

Re: Serial custom speed deprecated?

[Krzysztof Halasa]

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

Re: Serial custom speed deprecated?

[linux-os (Dick Johnson)]

On Thu, 24 Aug 2006, Krzysztof Halasa wrote:

> 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

But the baud-rates have always been some approximation that starts
at 75 and increases by powers-of-two. This is because the hardware
always had fixed clocks with dividers that divided by powers-of-two.
What is the claim for the requirement of strange baud-rates set
as an integer of dimension "baud?" Where does this requirement
come from and what devices use these?

FYI, the EXTA and EXTB were added to accommodate UARTS that
had hardware pre-scalers so that portion of the 'int' was
translated and went somewhere else than the UART divisor.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Serial custom speed deprecated?

[Alan Cox]

Ar Iau, 2006-08-24 am 16:43 -0400, ysgrifennodd linux-os (Dick Johnson):
> at 75 and increases by powers-of-two. This is because the hardware
> always had fixed clocks with dividers that divided by powers-of-two.
> What is the claim for the requirement of strange baud-rates set
> as an integer of dimension "baud?" Where does this requirement
> come from and what devices use these?

A lot of chips will do all sorts of interesting speeds such as 31.5Kbit
because today the clocks are themselves quite configurable.

Re: Serial custom speed deprecated?

[Rogier Wolff]

On Thu, Aug 24, 2006 at 11:11:41PM +0100, Alan Cox wrote:
> Ar Iau, 2006-08-24 am 16:43 -0400, ysgrifennodd linux-os (Dick Johnson):
> > at 75 and increases by powers-of-two. This is because the hardware
> > always had fixed clocks with dividers that divided by powers-of-two.
> > What is the claim for the requirement of strange baud-rates set
> > as an integer of dimension "baud?" Where does this requirement
> > come from and what devices use these?

> A lot of chips will do all sorts of interesting speeds such as
> 31.5Kbit because today the clocks are themselves quite configurable.

More importantly, the base-clocks are getting higher and higher, and
the division is no longer a "power-of-two". Thus 9600 is no longer
2.456MHz / 2^8, but something like 33MHz / 3438. This allows modern
hardware to run much faster baud rates, as well as custom slower baud
rates.

Note that IMHO, we should have started hiding this mess from /drivers/
a long time ago. The tty layer should convert the B_9600 thingies to
"9600", the integer, and then call the set_termios function. The
driver should be prohibited from looking at how the the baud rate came
to be 9600, and attempt to approach the requested baud rate as good as
possible. It might return a flag somewhere: Not exact. In the example
above, the resulting baud rate is about 1.4 baud off: 9598.6. This is
not a problem in very many cases.

Once this is in place, you lose a lot of "figure out the baud rate
integer from the B_xxx settings" code in all the drivers, as well as
that we get to provide a new interface to userspace without having to
change ALL drivers at the same time. This decouples the drivers from
the kernel<->userspace interface.

	Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

Re: Serial custom speed deprecated?

[Russell King]

On Sun, Aug 27, 2006 at 08:52:11AM +0200, Rogier Wolff wrote:
> Once this is in place, you lose a lot of "figure out the baud rate
> integer from the B_xxx settings" code in all the drivers, as well as
> that we get to provide a new interface to userspace without having to
> change ALL drivers at the same time. This decouples the drivers from
> the kernel<->userspace interface.

This has been helped along by serial_core - drivers have helper
functions which they call (along with their min/max baud rate)
which handles all this stuff.

The one thing your idea is missing is how to handle the "user
requested 15mbaud but I can only do 115200baud" case - POSIX
prefers you to report back what you actually selected rather
than error out.  If you merely pass an integer to the drivers,
they can't do that.

Note also that some drivers effectively have run-time configurable
max baud rates, so you can't pass a fixed set of capabilities to
the tty layer on driver initialisation.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

RE: Serial custom speed deprecated?

[Stuart MacDonald]

From: On Behalf Of Rogier Wolff
> Note that IMHO, we should have started hiding this mess from /drivers/
> a long time ago. The tty layer should convert the B_9600 thingies to
> "9600", the integer, and then call the set_termios function. The
> driver should be prohibited from looking at how the the baud rate came
> to be 9600, and attempt to approach the requested baud rate as good as
> possible. It might return a flag somewhere: Not exact. In the example
> above, the resulting baud rate is about 1.4 baud off: 9598.6. This is
> not a problem in very many cases.
> 
> Once this is in place, you lose a lot of "figure out the baud rate
> integer from the B_xxx settings" code in all the drivers, as well as
> that we get to provide a new interface to userspace without having to
> change ALL drivers at the same time. This decouples the drivers from
> the kernel<->userspace interface.

I'll second the motion. :-)

..Stu

Re: Serial custom speed deprecated?

[Russell King]

On Mon, Aug 28, 2006 at 10:14:30AM -0400, Stuart MacDonald wrote:
> From: On Behalf Of Rogier Wolff
> > Note that IMHO, we should have started hiding this mess from /drivers/
> > a long time ago. The tty layer should convert the B_9600 thingies to
> > "9600", the integer, and then call the set_termios function. The
> > driver should be prohibited from looking at how the the baud rate came
> > to be 9600, and attempt to approach the requested baud rate as good as
> > possible. It might return a flag somewhere: Not exact. In the example
> > above, the resulting baud rate is about 1.4 baud off: 9598.6. This is
> > not a problem in very many cases.
> > 
> > Once this is in place, you lose a lot of "figure out the baud rate
> > integer from the B_xxx settings" code in all the drivers, as well as
> > that we get to provide a new interface to userspace without having to
> > change ALL drivers at the same time. This decouples the drivers from
> > the kernel<->userspace interface.
> 
> I'll second the motion. :-)

You might do, but it's incompatible with the POSIX standard.  As I
explained to Rogier (he took it off list) there's no need for "inexact"
flags.

If we pass a baud rate via tcsetattr() (or ioctl), you should set what
ever settings you can.  If you can set _no_ settings, you return an
error.  If you can set at least one setting, you do not return an error,
and you only set those settings you can do.

When you subsequently read the settings via tcgetattr(), POSIX requires
that the returned information be what the port is _actually_ doing.

So, this means that if you can only do 9599 baud and not 9600 baud,
maybe you should be returning 9599 baud.

On the same subject, if you don't support RTS/CTS flow control, and
userland requests CRTSCTS, you shouldn't be allowing CRTSCTS to be set.
And indeed, if you don't allow that in the kernel today, stty will
correctly issue a warning that it was "unable to perform all requested
operations".

So, while I whole heartedly agree with passing baud rates numerically,
I do not think we need any of this inexact flagging nonsense provided
we implement something as userland programs expect - iow, the POSIX
behaviour.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Serial custom speed deprecated?

[Rogier Wolff]

On Mon, Aug 28, 2006 at 09:09:18PM +0100, Russell King wrote:

> So, while I whole heartedly agree with passing baud rates
> numerically, I do not think we need any of this inexact flagging
> nonsense provided we implement something as userland programs expect
> - iow, the POSIX behaviour.

I fully agree we should implement Posix behaviour. Wether that specifies
what userland programmers expect is where I disagree. 

If you happen to change RTS/CTS at the same time as you change baud,
the call will return succes, even though the most important part (for
you) of your call failed. Note that if the succes of the call depends
on the previous state of RTS/CTS. Thus the error will depend on
whatever happened before. This creates difficult-to-diagnose problems
for sysadmins. 

Anyway, this would not happen if the programmer had read the full text
of the POSIX spec. IMHO, most programmers have a good idea of the
filosopy, and program against that: If some call fails it returns
error.

Anyway, here I am again rambling against the Posix spec. But again:
we should implement POSIX as good as we can. Alan already did the
most important footwork. Good job!

	Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

Re: Serial custom speed deprecated?

[Russell King]

On Tue, Aug 29, 2006 at 08:20:49AM +0200, Rogier Wolff wrote:
> On Mon, Aug 28, 2006 at 09:09:18PM +0100, Russell King wrote:
> > So, while I whole heartedly agree with passing baud rates
> > numerically, I do not think we need any of this inexact flagging
> > nonsense provided we implement something as userland programs expect
> > - iow, the POSIX behaviour.
> 
> I fully agree we should implement Posix behaviour. Wether that specifies
> what userland programmers expect is where I disagree. 
> 
> If you happen to change RTS/CTS at the same time as you change baud,
> the call will return succes, even though the most important part (for
> you) of your call failed. Note that if the succes of the call depends
> on the previous state of RTS/CTS. Thus the error will depend on
> whatever happened before. This creates difficult-to-diagnose problems
> for sysadmins.

I disagree.  POSIX recommends the following sequence when setting termios
modes:

	tcgetattr(fd, &termios);
	/* modify termios */
	if (tcsetattr(fd, &termios) == -1)
		/* whatever error handling, none of the modes worked */
	tcgetattr(fd, &real_termios);

and in that respect it's the classic negotiation between two differing
sets of code - the application asks for what it wants, and then requests
what it actually got.  It can then check real_termios to see if the
settings it actually got are compatible with what it wants to achieve.

For example, if it couldn't enable CRTSCTS, it might decide to use XON/
XOFF flow control instead.

If tcsetattr() were to return an error if _any_ mode failed, then you
wouldn't know if it failed because CRTSCTS wasn't supported, or the
baud rate, or maybe some other mode you asked for.  That's multiple
times worse, and it would actually result in lots of programs failing
just because one setting wasn't supported - and will result in more
sysadmins scratching their collective heads.

So, the key idea here is that fiddling with termios is a _negotiation_
between the application and the driver.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

RE: Serial custom speed deprecated?

[Stuart MacDonald]

From: On Behalf Of linux-os (Dick Johnson)
> But the baud-rates have always been some approximation that starts
> at 75 and increases by powers-of-two. This is because the hardware
> always had fixed clocks with dividers that divided by powers-of-two.
> What is the claim for the requirement of strange baud-rates set
> as an integer of dimension "baud?" Where does this requirement
> come from and what devices use these?

Perhaps you'd like to check out our products
http://www.connecttech.com/

We build a lot of custom boards that have odd clocks to generate very
odd baud rates for random serial devices. The Bxxx style has been a
thorn in my side since 1999.

Also, Oxford's 16PCI95x family has three different points of altering
the clock; the clock prescaler, the actual sample rate (which is the
classic /16 that most are used to), and the actual divisor. That can
produce pretty much any baud rate, albeit with some error.

..Stu

RE: Serial custom speed deprecated?

[linux-os (Dick Johnson)]

On Fri, 25 Aug 2006, Stuart MacDonald wrote:

> From: On Behalf Of linux-os (Dick Johnson)
>> But the baud-rates have always been some approximation that starts
>> at 75 and increases by powers-of-two. This is because the hardware
>> always had fixed clocks with dividers that divided by powers-of-two.
>> What is the claim for the requirement of strange baud-rates set
>> as an integer of dimension "baud?" Where does this requirement
>> come from and what devices use these?
>
> Perhaps you'd like to check out our products
> http://www.connecttech.com/
>
> We build a lot of custom boards that have odd clocks to generate very
> odd baud rates for random serial devices. The Bxxx style has been a
> thorn in my side since 1999.
>
> Also, Oxford's 16PCI95x family has three different points of altering
> the clock; the clock prescaler, the actual sample rate (which is the
> classic /16 that most are used to), and the actual divisor. That can
> produce pretty much any baud rate, albeit with some error.
>
> ..Stu
>

Well when you change things, remember that you need not only something
that translates B9600 to your new 9600 (trivial it's a #define, but
ALSO (very important!) B0 needs to hang up the modem! This means
that some value (perhaps 0), as a divisor, needs to perform this
same function.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Serial custom speed deprecated?

[Alan Cox]

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

Re: Serial custom speed deprecated?

[Krzysztof Halasa]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

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

I think it makes most sense.

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

I think compatibility at the source level is good here. UTF-8 looks
nice, though.

I think it could remain compatible - c_cc[] could grow into array of
multibyte characters with:
#define VINTR 0
#define VQUIT (1 * n)
#define VERASE (2 * n)
#define VKILL (3 * n)

where n is max number of UTF-8 bytes (5 for 32-bit UCS?)

I'm not sure if UTF-8 control codes are needed in practice, though
(I mean I just don't know).

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

A bit messy I think. I think the first way is much better. Especially
when we have multiple changes (speed and UTF-8, for example).

>> Not sure if we want int, uint, or long long for speed values :-)
>
> You want speed_t according to POSIX.

Sure, I meant what does speed_t resolve to.

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

While obviously I'm not glibc (nor termios) expert I don't think
we should expect problems. New glibc would just issue the old ioctl
if the new one isn't available. I think similar things are already
in place.
Glibc could be compiled with minimum kernel version = 2.6.20 or so
to assume the new ioctls are always present.
-- 
Krzysztof Halasa

RE: Serial custom speed deprecated?

[Stuart MacDonald]

From: On Behalf Of Alan Cox
> 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

I think if a numeric baud rate is going to be supported, getting away
from the B* cruft is important. Just use a number.

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

I'd say yes.

..Stu

Re: Serial custom speed deprecated?

[Russell King]

On Fri, Aug 25, 2006 at 11:21:21AM -0400, Stuart MacDonald wrote:
> From: On Behalf Of Alan Cox
> > 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
> 
> I think if a numeric baud rate is going to be supported, getting away
> from the B* cruft is important. Just use a number.

The "B* cruft" is part of POSIX so needs to be retained.  These are
used in conjunction with with cfgetispeed(), cfgetospeed(), cfsetispeed()
and cfsetospeed() to alter the baud rate settings in the termios
structure in an implementation defined manner.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

RE: Serial custom speed deprecated?

[Stuart MacDonald]

From: On Behalf Of Russell King
> The "B* cruft" is part of POSIX so needs to be retained.  These are

Ah, ok. Didn't know that.

..Stu

RE: Serial custom speed deprecated?

[linux-os (Dick Johnson)]

On Fri, 25 Aug 2006, Stuart MacDonald wrote:

> From: On Behalf Of Russell King
>> The "B* cruft" is part of POSIX so needs to be retained.  These are
>
> Ah, ok. Didn't know that.
>
> ..Stu

... and why "B0" is important as well.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.62 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Serial custom speed deprecated?

[Theodore Tso]

On Fri, Aug 25, 2006 at 08:32:03PM +0100, Russell King wrote:
> On Fri, Aug 25, 2006 at 11:21:21AM -0400, Stuart MacDonald wrote:
> > From: On Behalf Of Alan Cox
> > > 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
> > 
> > I think if a numeric baud rate is going to be supported, getting away
> > from the B* cruft is important. Just use a number.
> 
> The "B* cruft" is part of POSIX so needs to be retained.  These are
> used in conjunction with with cfgetispeed(), cfgetospeed(), cfsetispeed()
> and cfsetospeed() to alter the baud rate settings in the termios
> structure in an implementation defined manner.

The B* cruft has to be maintained.

But it would be POSIX complaint for B9600 to be #defined to B9600, and
B19200 to be #defined to B19200.

What would scare me though about doing something like would be
potential for the ABI changes.  Not only do you have to worry about a
consistent set of ioctl's, structure definitions, and B* defines, but
you also have to worry about userspace libraries that use B* as part
of their interface, and expect user programs to pass B* constants to
the userspace library.  (Say, some kind of conveience dialout library,
for example.)

In that case, the application could have been compiled with the
new-style termios.h, but the userspace library could have been
compiled with the old-style termios.h, and hence the old-style ioctl
definitions, and the opportunities for mischief are endless.

					- Ted

Re: Serial custom speed deprecated?

[Krzysztof Halasa]

Theodore Tso <tytso@mit.edu> writes:

> What would scare me though about doing something like would be
> potential for the ABI changes.  Not only do you have to worry about a
> consistent set of ioctl's, structure definitions, and B* defines, but
> you also have to worry about userspace libraries that use B* as part
> of their interface, and expect user programs to pass B* constants to
> the userspace library.  (Say, some kind of conveience dialout library,
> for example.)

Right, there is a potential problem here. I don't know | think
if anything like that exists, though. If there is no such software
the issue can be ignored, and if something turns out then it just
have to be compiled with the same glibc headers (both parts).
That probably means even for binary software it's a non-issue.
-- 
Krzysztof Halasa

RE: Serial custom speed deprecated?

[Stuart MacDonald]

From: On Behalf Of Krzysztof Halasa
> Not sure if we want int, uint, or long long for speed values :-)

Our max baud rate on any product is IIRC 1,8432,00. I checked with our
hardware guys, and they think the current theoretical upper limit is
around 30,000,000.

<words style="famous,last">
A uint ought to be enough for anybody.
</words>

..Stu

Re: Serial custom speed deprecated?

[Russell King]

On Thu, Aug 24, 2006 at 06:41:33PM +0100, Alan Cox wrote:
> We would need a driver ->set_speed method for the cases where
> - ioctl is called to set specific board rate
> - OR termios values for tty speed change
> - While we are at it we might want to make ->set_termios also allowed to
> fail

That's a little dodgy, from my reading of POSIX.  ISTR POSIX prefers
a behaviour of "set what you can" from this, and when you read back
the termios settings, you get the actual settings in use.

So, eg, if you don't support CS5 but the previous setting was CS8,
tcsetattr should not return an error.  The device itself should set
the other changed parameters but remain at CS8 and tcgetattr should
report CS8.

stty already knows about this, and issues warnings when you attempt
to set stuff which aren't supportted by the driver (assuming you have
a correctly behaving driver in this respect.)  I've been a little
scared to push the implementation for these in the serial drivers.

> Anyone got any problems with this before I go and implement it ?

Only as long as we can end up with a numeric baud rate at the end of
the day (which is what serial has always been after.)

This represents a major improvement to the tty interface, thanks for
looking in to making it happen.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

RE: Serial custom speed deprecated?

[Stuart MacDonald]

From: On Behalf Of Alan Cox
> At this point I think we need
> 
> -	An ioctl to set/get the actual baud rate input/output
> -	Some kind of termios flag to indicate they are being 
> used (as we have
> CBAUDEX now). [We could "borrow" the 4Mbit one and dual use it IMHO]
> 
> For drivers tty_get_baud_rate would return the actual speed as before.
> 
> We would need a driver ->set_speed method for the cases where
> - ioctl is called to set specific board rate
> - OR termios values for tty speed change
> - While we are at it we might want to make ->set_termios also 
> allowed to fail
> 
> [and if you had no ->set_speed method non standard speeds would be
> refused by the tty layer for back compat]
> 
> Anyone got any problems with this before I go and implement it ?

Sounds good.

..Stu

RE: Serial custom speed deprecated?

[Alan Cox]

Ar Iau, 2006-08-24 am 08:41 -0400, ysgrifennodd Stuart MacDonald:
> The easiest thing is likely to add a new ioctl to serial_core.c
> specifically for setting the baud rate. It takes an integer baud rate
> and returns success or error. It will need to be able to call a

It should take a pair, a send rate and a receive rate. We need that to
cover some corner cases.

> Hm, after some thought I think the core won't actually end up doing
> anything except dispatching. So the better way is to add ioctls to the
> subdrivers directly.

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.


Alan

RE: Serial custom speed deprecated?

[David Woodhouse]

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