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

[Rob Landley]

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...)

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.

Rob