FreeCalypso > hg > freecalypso-tools
view rvinterf/doc/rvinterf.usage @ 465:003e48f8ebe1
rvinterf/etmsync/fsnew.c: cast 0 to (char *) for execl sentinel
I generally don't use NULL and use plain 0 instead, based on a "NULL
considered harmful" discussion on the classiccmp mailing list many aeons
ago (I couldn't find it, and I reason that it must have been 2005 or
earlier), but a recent complaint by a packager sent me searching, and I
found this:
https://ewontfix.com/11/
While I don't give a @#$% about "modern" systems and code-nazi tools,
I realized that passing a plain 0 as a pointer sentinel in execl is wrong
because it will break on systems where pointers are longer than the plain
int type. Again, I don't give a @#$% about the abomination of x86_64 and
the like, but if anyone ever manages to port my code to something like a
PDP-11 (16-bit int, 32-bit long and pointers), then passing a plain 0
as a function argument where a pointer is expected most definitely won't
work: if the most natural stack slot and SP alignment unit is 16 bits,
fitting an int, with longs and pointers taking up two such slots, then
the call stack will be totally wrong with a plain 0 passed for a pointer.
Casting the 0 to (char *) ought to be the most kosher solution for the
most retro systems possible.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Mon, 11 Feb 2019 00:00:19 +0000 |
| parents | e7502631a0f9 |
| children |
line wrap: on
line source
Rvinterf (the specific program by this name) is an extended version of rvtdump (see rvtdump.usage) that decodes and dumps and/or logs any and all output generated by the firmware running on the target just like rvtdump, but also creates a local UNIX domain socket on the host machine to which "client" programs can connect. "Client" programs connecting to rvinterf via this local socket interface can: 1. Receive copies of selected RVTMUX packets coming from the target; 2. Send arbitrary RVTMUX packets toward the target. Rvinterf is invoked just like rvtdump: rvinterf [options] /dev/ttyXXX The following options have the same meaning as in rvtdump, see rvtdump.usage for the details: -b, -B, -d and -l. The only difference is that -b without -l is potentially useful and thus allowed. Additional rvinterf options which don't exist in rvtdump are: -n Suppress the output on stdout like -b, but don't fork into background. This option is passed by "client" programs when they invoke rvinterf behind the scenes instead of connecting to an already-running rvinterf instance. -s pathname_for_socket By default the local UNIX domain socket created by rvinterf is bound to /tmp/rvinterf_socket; this option allows any other pathname to be specified. -S <file descriptor number> This option is not meant for direct use by human users. It is passed by "client" programs when they invoke rvinterf behind the scenes with an unnamed and unbound socket pair instead of conecting to an already- running rvinterf instance. -w number_in_seconds It has been discovered experimentally that if an RVTMUX packet is sent to a target when the latter is in the "deep sleep" state, the target wakes up, but the packet that was sent is not received correctly. TI's reference fw seems to wait for 10 s after last serial activity before falling into deep sleep (provided that all other conditions for that sleep mode are satisfied), hence the following workaround has been implemented in rvinterf: if a packet is to be sent to the target and more than a set time has elapsed since the last transmitted packet, the packet is preceded by a "wake-up shot" of 64 0 bytes (outside of a packet, ignored by the fw) and a 100 ms pause. This hack is not pretty, but it appears to do its job of making RVTMUX communication with target firmwares reliable. The -w option changes the elapsed time threshold at which the "wake-up shot" is sent; the default is 7 s. Specify -w 0 to disable this hack altogether.