[Toybox] [PATCH] Use NULL rather than 0 in vargs. (Rob Landley)

[James McMechan]

On Mon, Dec 11, 2017 at 10:05 AM, Rob Landley <rob at landley.net> wrote:
> On 12/10/2017 08:30 PM, James McMechan wrote:
>> Yes, history still has a lot of sharp teeth waiting to bite.
>> Alas, it is not just old buildings, people are still producing stuff
>> with oddball settings.
>> e.g. my controller software is hardcoded to 7-o-1.5 make the
>> replacement work like the old stuff did.
>> then a few years later, make the new controller software work with the old gear.
>> So both ends have been replaced, only the format between them has not changed :(
>
> You've "grandma's axe"ed a protocol.
>
> *shrug* Ok, still need the serial port setting stuff. The problem is I
> have no idea how to _test_ it. (All the serial hardware I have at this
> point is USB, and QEMU's serial emulation copies characters into and out
> of the I/O registers in all the drivers I've looked at. Last time I
> looked at serial data in an oscilloscope was 2012, I just don't have the
> hardware at the moment...)

*shrug* back...
If all you want to do is verify that the command works like the
distribution version
any real serial port hardware should work, I use PL2303, CP210X, or
FTDI USB->serial
all of which seem to work ok, the hardware is stateful so unless your
distro starts
a getty on it you could just grab one and try it. or a raspberry pi,
or old pc or whatever.
something like
cat /dev/ttyUSB0 & #grab and hold the port
a=`stty -a </dev/ttyUSB0` # get the initial serial port setup using distro tools
stty intr ^A </dev/ttyUSB0 # change it using distro tools
b=`stty -a </dev/ttyUSB0` # get the setup using distro tools
stty intr ^C </dev/ttyUSB0 # change it back using distro tools
c=`stty -a </dev/ttyUSB0` # get the setup again using distro toools
toybox stty intr ^a </dev/ttyUSB0 # change it using toybox
d=`stty -a </dev/ttyUSB0` # get the results using distro tools
stty intr ^C </dev/ttyUSB0 # change it back using distro tools
a == c && b == d && a != b for success
If you are not using the serial port you can twiddle to your heart's content.

> I suppose I can use strace and check that the right stuff is going into
> the syscalls, but that's a manual check not an automated regression
> test. (I'm not creating regression tests with strace just now, thanks.)
>
> In general the problem I have poking at stty right now is I dunno how to
> regression test my changes...
>
>> And it seems no one wants to replace both ends at the same time, even
>> if they did
>> it would likely be only one of the 17 pieces of gear that would be
>> replaced with the controller,
>> and I usually it would break something...
>>
>> There were even some good reasons for some of it, a open wire would
>> produce a stream
>>  with bad checksums for odd parity.
>>
>>> 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...
>>
>> I don't think it ever has, there was likely a reason 30 years ago,
>> that I have forgotten.
>
> All the implementations I'e seen did open(); dup(); dup(); but I didn't
> know they were _required_ to. :)
>
> Let's see...
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html
> doesn't seem to mention that, how about
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05
>
>> At program start-up, three streams are predefined and need not be
>> opened explicitly: standard input (for reading conventional input),
>> standard output (for writing conventional output), and standard error
>> (for writing diagnostic output). When opened, the standard error
>> stream is not fully buffered; the standard input and standard output
>> streams are fully buffered if and only if the stream can be determined
>> not to refer to an interactive device.
>
> Nope, that's not it...
>
>>> that have some meaning? (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?)
>>
>> I too have been working with the USB serial ports, mostly it is nice.
>> The custom of having the reference voltage on board next to the TX/RX
>> does make life much easier, just pulling the jumper on the USB board
>> and hooking it up to the reference makes it simpler.
>>
>> Except of course when the manufacture puts something like a 5V supply
>> next to a 3.3V serial port, I unfortunately have some of these.
>>
>> The other problem of the hardware comes up in something old fashioned
>> like 9600-8-n-1 if you are lucky, means that until you are fully booted
>> you get to watch the screen slowly scroll.
>
> The Numato Mimas v2 (most powerful $50 FPGA board I've seen) has USB
> serial port hardware set to a fixed rate by the firmware, meaning when
> you boot j-core linux on the thing you have to set it to 9600. There's a
> firmware you can flash into it that sets it to 115200, but it's a
> separate firmware (not the spi flash the FPGA loads from) and the only
> tool they give you to update it is a windows binary.
>
> Sigh.
>
> Anyway, what I can test once by hand and what I can figure out how to do
> automated regression tests for are two different things. I really prefer
> toybox not require special hardware setups to test stuff, but qemu
> doesn't emulate at this level. Its serial port abstraction is a byte
> transport to and from a host filehandle.

For testing you don't need the serial port to work, just to report changes
to the kernel which will reply to userspace with the results.
I do not usually use too much emulation since it frequently seems to
break in my area of interest.
Your test is not so much of the hardware but of the userspace->kernel API
If toybox tells the kernel to do the right thing and it fails that is
a kernel bug.

> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net