Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux>
  3. Kernel
1 2  View All
Serial custom speed deprecated?
stuartm at connecttech
Aug 23, 2006, 2:41 PM
Post #1 of 43 (20392 views)
Permalink
From
http://www.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.64

"<dwmw2@dwmw2.baythorne.internal>
Complain about setting custom speed or divisor on serial ports."

And the relevant patch hunk:
@@ -832,8 +826,17 @@
goto exit;
if (info->flags & UIF_INITIALIZED) {
if (((old_flags ^ port->flags) & UPF_SPD_MASK) ||
- old_custom_divisor != port->custom_divisor)
+ old_custom_divisor != port->custom_divisor) {
+ /* If they're setting up a custom divisor or speed,
+ * instead of clearing it, then bitch about it. No
+ * need to rate-limit; it's CAP_SYS_ADMIN only. */
+ if (port->flags & UPF_SPD_MASK) {
+ printk(KERN_NOTICE "%s sets custom speed on %s%d. This is deprecated.\n",
+ current->comm, info->tty->driver.name,
+ info->port->line);
+ }
uart_change_speed(info, NULL);
+ }
} else
retval = uart_startup(info, 1);
exit:

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.

..Stu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
dwmw2 at infradead
Aug 24, 2006, 2:18 AM
Post #2 of 43 (20273 views)
Permalink
On Wed, 2006-08-23 at 17:41 -0400, Stuart MacDonald wrote:
> 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.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
stuartm at connecttech
Aug 24, 2006, 5:41 AM
Post #3 of 43 (20294 views)
Permalink
From: David Woodhouse [mailto:dwmw2@infradead.org]
> On Wed, 2006-08-23 at 17:41 -0400, Stuart MacDonald wrote:
> > 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.

Agreed. Our products have required this functionality since at least
1999.

It appears that the current method has been deprecated before the next
method has been constructed though. Is that correct?

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
subdriver's set_baud_rate() as well, which means extending the ops
structure, because some hardware (like the XR16C954 IIRC) has
non-standard ways of actually programming the baud rate.

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.

..Stu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
dwmw2 at infradead
Aug 24, 2006, 6:03 AM
Post #4 of 43 (20301 views)
Permalink
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
alan at lxorguk
Aug 24, 2006, 6:19 AM
Post #5 of 43 (20321 views)
Permalink
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
khc at pm
Aug 24, 2006, 9:27 AM
Post #6 of 43 (20293 views)
Permalink
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
?
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
alan at lxorguk
Aug 24, 2006, 10:23 AM
Post #7 of 43 (20333 views)
Permalink
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 ?






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
khc at pm
Aug 24, 2006, 11:51 AM
Post #8 of 43 (20305 views)
Permalink
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
linux-os at analogic
Aug 24, 2006, 1:43 PM
Post #9 of 43 (20289 views)
Permalink
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/
_


****************************************************************
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
rmk+lkml at arm
Aug 24, 2006, 3:05 PM
Post #10 of 43 (20308 views)
Permalink
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
alan at lxorguk
Aug 24, 2006, 3:11 PM
Post #11 of 43 (20275 views)
Permalink
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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
alan at lxorguk
Aug 24, 2006, 3:43 PM
Post #12 of 43 (20277 views)
Permalink
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
khc at pm
Aug 25, 2006, 3:58 AM
Post #13 of 43 (20266 views)
Permalink
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
nick at craig-wood
Aug 25, 2006, 4:40 AM
Post #14 of 43 (20264 views)
Permalink
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Iau, 2006-08-24 am 20:51 +0200, ysgrifennodd Krzysztof Halasa:
> > Not sure if we want int, uint, or long long for speed values :-)
>
> You want speed_t according to POSIX.

To get non-integral baud rates (of which there are a few but no longer
in common use) you'd probably want to supply a two integers which you
then divide.

This matches most hardware quite well, and for most cases you'd just
supply the divisor as 1.

--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
stuartm at connecttech
Aug 25, 2006, 8:01 AM
Post #15 of 43 (20271 views)
Permalink
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
stuartm at connecttech
Aug 25, 2006, 8:10 AM
Post #16 of 43 (20260 views)
Permalink
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
stuartm at connecttech
Aug 25, 2006, 8:17 AM
Post #17 of 43 (20269 views)
Permalink
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
stuartm at connecttech
Aug 25, 2006, 8:21 AM
Post #18 of 43 (20293 views)
Permalink
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
linux-os at analogic
Aug 25, 2006, 8:52 AM
Post #19 of 43 (20277 views)
Permalink
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/
_


****************************************************************
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
rmk+lkml at arm
Aug 25, 2006, 12:32 PM
Post #20 of 43 (20266 views)
Permalink
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
stuartm at connecttech
Aug 25, 2006, 1:21 PM
Post #21 of 43 (20244 views)
Permalink
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
tytso at mit
Aug 25, 2006, 1:39 PM
Post #22 of 43 (20291 views)
Permalink
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Serial custom speed deprecated? [ In reply to ]
linux-os at analogic
Aug 25, 2006, 1:54 PM
Post #23 of 43 (20249 views)
Permalink
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/
_


****************************************************************
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
khc at pm
Aug 26, 2006, 5:16 AM
Post #24 of 43 (20262 views)
Permalink
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial custom speed deprecated? [ In reply to ]
linux at horizon
Aug 26, 2006, 11:16 AM
Post #25 of 43 (20256 views)
Permalink
> 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.

Actually, we're not QUITE out of bits. CBAUDEX | B0 is not taken.
That would make a reasonable encoding for a custom speed.
(But I haven't checked glibc... ah, yes, it should work!
See glibc-2.4/sysdeps/unix/sysv/linux/speed.c; browse at
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/?cvsroot=glibc
if you don't have a local copy source handy.)

What I'd do is, when converting to the old-style for tcgetattr, if the
current baud rate is not representable, cache it somewhere and return that
(or some other magic value). If a tcsetatt call comes in that specifies
that magic value, use the cached baud rate.

If you make the cache just the current baud rate setting (the magic
value on set means "don't alter"), that will handle a lot of programs
that just want to play with handshaking.

If you make the cache separate, you can also survive an
old-interface-using program switching to a different baud rate and then
switching back.


Also note that if you truly want to support all baud rates in historical
use, you'll need to include at least one fractional bit for 134.5 baud.
(Unless you're sure that IBM 2741 terminals are truly dead. :-))

Alternatively, you could observe that asynchronous communications only
requires agreement withing 5% between sender and receiver, so specifying
a baud rate to much better than 1% is not too important.

Half-precision floating point would be ideal for the job. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
1 2  View All

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal