Differential D29209
termios: add B1500000 Authored by bz on Mar 10 2021, 10:30 PM. Tags None Referenced Files
Subscribers
Details A lot of small arm64 gadgets are using 1500000 as console speed. MFC-after: 6 weeks
Diff Detail
Event TimelineComment Actions 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 ;-) Comment Actions 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. Comment Actions 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. Comment Actions 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. Comment Actions 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. |