Page MenuHomeFreeBSD

termios: add B1500000
ClosedPublic

Authored by bz on Mar 10 2021, 10:30 PM.

Details

Summary

A lot of small arm64 gadgets are using 1500000 as console speed.
While cu can perfectly deal with this some 3rd party software, e.g.,
comms/conserver-con add speeds based on B<n> being defined.
Having it defined here simplifies enhancing other software a lot.

MFC-after: 6 weeks

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

bz requested review of this revision.Mar 10 2021, 10:30 PM

Sorry for adding you all as reviewers; termios doesn't get too many commits these days so either I think you are clusteradm using conserver-con (which I'll send a 3-line patch for), arm64 user and might be interested in this in general, or some person with a lot of wisdom I think who might want to say something about this. Pick your own category and change reviewers as you see fit ;-)

philip requested changes to this revision.Mar 11 2021, 1:28 AM

I have had a local patch for this for ages. My patch has:

#define	B1000000 1000000
#define	B1152000 1152000
#define	B1500000 1500000
#define	B2000000 2000000
#define	B2500000 2500000
#define	B3000000 3000000
#define	B3500000 3500000
#define	B4000000 4000000

The commit message says I cribbed these from glibc.

I would suggest also adding the other constants.

This revision now requires changes to proceed.Mar 11 2021, 1:28 AM

Many years ago, we're talking 386BSD/FreeBSD1 days, I made a patch where you could set any damn rate you wanted, and the math would happen.

It wasn't particularly hard to implement, but it got brucified so bad I just dropped it.

In D29209#654049, @phk wrote:

Many years ago, we're talking 386BSD/FreeBSD1 days, I made a patch where you could set any damn rate you wanted, and the math would happen.

It wasn't particularly hard to implement, but it got brucified so bad I just dropped it.

At the risk of laying down the foundations for a fine new bikeshed: could it cope with MIDI? That might actually be nice to have under some circumstances.

That shouldn't block progress on this patch though. It's fine as-is. I'd just add the extra rates to put us on feature parity with Linux/glibc.

In D29209#654049, @phk wrote:

Many years ago, we're talking 386BSD/FreeBSD1 days, I made a patch where you could set any damn rate you wanted, and the math would happen.

It wasn't particularly hard to implement, but it got brucified so bad I just dropped it.

Someone else also did this. All the 'speed' arguments are a baud rate and the B values are there for the convenience of old (really really old) software. They were introduced in V6 Unix, but were defined in getty.c itself. The numbers matched arrays/bare constants in the drivers. The B numbers weren't used in the kernel. V7 moved them into /usr/include/gtty.h, but none of the kernel drivers were converted. In fact, everything through 4.4BSD had the drivers know the Bxxxx values and they had tables, or did a bit of math to convert the small numbers to values to put into registers. Almost none referenced them, and when they did it was to set a default baud rate...

The B numbers date from a time when hardware couldn't cope with arbitrary values and you had to bang in 12 if you wanted 9600 baud, but 10 if you wanted 4800 or maybe 9 for 2400. These days, any old number will do. cfsetspeed just takes a number.

Nearly all the drivers in the tree can take any number. There's about a half dozen USB drivers that have a specific value for each baud rate that's not a nice formula. They are the only real use of B9600 in the kernel... And I suspect that software archeology will show they were ported from Linux where the B numbers are still a translation layer.

I'm cool with this or philip's patches due to the post-processing that some programs do to find 'legal' values though. It's lame, but there's no reason we shouldn't accomodate the lameness.

Updated with more values based on NetBSD.

This revision is now accepted and ready to land.Mar 18 2021, 10:43 AM
This revision was automatically updated to reflect the committed changes.