On Sun, Dec 10, 2017 at 12:28 PM, Rob Landley <[email protected]> wrote: > My first weekend back home in Austin, and GOING to pick something to > spend some time on, and I guess it's this. :) > > On 12/05/2017 11:32 AM, enh wrote: >> want me to switch to arrays? (and if so, presumably using ARRAY_LEN >> rather than an explicit end element?) > > I can do it as part of my cleanup pass. Let's see... > > You sent in commit eb7e847adcec removing periods from help text and then > submit a command with periods in help text. :)
always a problem trying to match someone else's style. (a check in the generator script might be a good idea.) > There is no tests/stty.test. I'm not entirely sure how to make one > either. Um... (Even with a qemu instance to test under, I'd need a pty > wrapper to automate testing of this. I've considered _writing_ a pty > wrapper for a while, it's in the "implement screen" bucket. And other > stuff like set baud and print baud... if it's the same implementation > setting and checking you're not showing that it's _right_, just that it > matches...) that was my problem too. i just did manual testing on throwaway terminals. > One of the reasons I hadn't done stty yet is I'm not sure how much of > the serial settings are relevant in 2017. Every serial port in the world > was 8-n-1 already in the 80's, so the even/odd/parity stuff is a > historical relic. me neither. that's why i'd got by with a much smaller subset. i wasn't going to add any of the "weird shit" from the end of the POSIX spec until i noticed that all the examples i could find (including on the toybox mailing list) tended to use those rather than the "canonical" forms. > Um, shouldn't stty operate on _stdout_ instead of stdin when modifying? > Hmmm... no, I guess not, the other one isn't doing so and "cooked/raw" > are stdin questions anyway. So yes, open stdin for _writing_. Which > presumably means the shell that launched us has to have opened stdin for > writing if it's a tty? I should write that down somewhere... > > Lots of things can be inlined, starting with do_stty(). > > Trivial code style tweaks: I generally don't put curly brackets around > single lines, and when an if () is multiline I put the curly bracket at > the start of the next line. Space after commas in function arguments > (unless removing some brings it under 80 columns to avoid a line split). > > Factor out xtcgetattr() doing the error handling (just into a static > function so it can still use the globals, only two calls but still a win). > > You have the baud list in microcom.c already, it should move to lib. i think i put in a TODO for that. i assumed it would be easier to get this in if the initial patch was self-contained. > And > I already did the bit pattern skipping compression, but I didn't make > the array unsigned short and multiply by 100 safter 57600. (It's the > same logic as the skip.) Query: why do you allow 0 as a baud value? Does > that have some meaning? it has _some_ meaning, though i admit i've no idea what. there's a constant for it, GNU stty lets you set it, the kernel doesn't complain and duly reports it back... > (The serial ports I've dealt with recently were > all USB so it was a packet protocol, and then the j-core uartlite device > is simple hardware running at a fixed speed, so I'm trying to think when > the last time is I set a serial port speed. Probably the cortex-m board, > but the kernel set the speed of that for me. Makes it kind of hard to > TEST any changes I make here, doesn't it?) > > N_TTY is 0 so all the low bounds of get_arg() are zero. I can cheat by > having all the non-option arguments come first, and then when we fall > down to the right point parse the next numerical argument... > > We don't actually care about the return value of tcsetattr() as long as > the returned data is right when we tcgetattr() on the next line. i did actually wonder about being clever because we basically have all the code to say "here's the difference between what i tried to set and what actually got set" in human-readable form, but i assumed no-one will ever need it. > I should check some of this in... > > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
