FreeCalypso > hg > freecalypso-tools
view rvinterf/doc/README.old @ 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
You are looking at the suite of FreeCalypso tools for talking to the RVTMUX interface provided by TI-based GSM firmwares. If you haven't already, please read ../doc/RVTMUX first. The fundamental difference between these tools and loadtools is that loadtools operate on a GSM device while its regular firmware is shut down, whereas the present rvinterf tools talk to active running GSM firmwares. The following tools are currently implemented: rvtdump Opens the serial port, decodes TI's binary packet protocol, and simply dumps every received/decoded packet on stdout in a human- readable form. No provision for sending anything to the target. Intended use: observing the debug trace output which all TI firmwares emit as standard "background noise". This utility allows one to observe/log/study the "noise" that appears on Pirelli's USB-serial port (running Pirelli's original fw), as well as that emitted on the IrDA (headset jack) port on the GTA02 by mokoN/leo2moko firmwares. rvinterf Provides a bidirectional interface to RVTMUX on the host side. It dumps and/or logs the "background noise" emitted by the target just like rvtdump, but also creates a local UNIX domain socket on the host machine to which other programs can connect, replicating the MUXing function on the host side. fc-tmsh Interactive asynchronous test mode shell. This program connects to a target GSM device through rvinterf and allows a developer- operator to send various ETM commands to the target. ETM responses are decoded (sometimes only lightly) and displayed. fc-tmsh is fully asynchronous in that it continuously listens (via select(2)) both for user input and for packets from the target at the same time, translating any user-entered commands into packets to the target and conversely, scribbling on the terminal when a packet arrives from the target. It has no knowledge of any correspondence between commands and responses they normally elicit. g23sh Like fc-tmsh (same asynchronous design), but for GPF/G23 rather than ETM. This tool and FreeCalypso project's understanding of GPF/G23 in general are currently in the earliest stages, so it is premature to try to describe it any further at this point. fc-sendsp Precursor to g23sh; even less worthy of further documentation. fc-fsio This program uses RVTMUX, ETM and TMFFS2 to access the live file system of a running GSM firmware. Of the existing proprietary firmwares, the only one that implements the TMFFS2 protocol required for fc-fsio is Pirelli's, to the best of our knowledge. This program connects to the target through rvinterf, but it differs from fc-tmsh in that it operates in a synchronous manner: the flow of operation is driven by user commands (just like in fc-loadtool), and every time the program sends an ETM command packet to the target, it expects a lock-step response. tfc139 See ../doc/Compal-unlock The fc-fsio, fc-tmsh and g23sh tools connect to the target not directly, but via rvinterf. Two usage scenarios are supported: 1. The user explicitly runs rvinterf (either directly or secondary to fc-xram, when testing an experimental FreeCalypso firmware ramImage), leaves it running (either backgrounded or in its own terminal window), and then runs one of the "client" programs: fc-fsio, fc-tmsh or g23sh. The two programs connect via local UNIX domain sockets on the host machine. 2. All of the "client" programs under discussion can also launch rvinterf themselves. An instance of rvinterf lauched in this manner becomes a child process of the "client" program, terminating together with it, and the two processes communicate via an unnamed and unbound socket pair.