If stdout is a tty, use vis(3) to print any filenames to prevent garbage
from being printed if the filename contains control- or other non-printable
characters.
While here, sprinkle some EXIT_FAILURE and NOTREACHED where appropriate.
if the exception address is < 1 page away from the KSP, switch to the that
CPU's spill stack to handle the trap. Otherwise you can get in a infinite
DSI fault loop.
but there are very small diffs in register definitions. For that, add
new options SSCOM_S3C{2800,2410,2400} and include appropriate
s3c*reg.h.
SSCOM_S3C2410 is also needed for interrupt controller differences.
and more) and use a little sig_header() helper.
- in selectdrives() make sure we don't overwrite some arrays. this makes
"iostat 1" work again on my really wide screens where defdrives (number that
can fit) was > ndrives (number of drives), rather than dump core trying to
print (char *)1...
code to emit profile counters and the FUNCTION_PROFILER macro in this
file emit/define the same label. For gcc 2.95.3 it used to work
because FUNCTION_PROFILER used local numeric labels instead of using
LABELNO, so it caused no conflict.
This makes -pg code compilable.
* Mark the actual Handspring Visor as type "VISOR" and all others
"PALM4" (notably, the Sony Clie 41 changes from Visor-type to
Palm4-type).
* For Palm4-type devices, use the GET_PALM_CONNECTION_INFORMATION
query instead of the GET_CONNECTION_INFORMATION query, and interpret
the returned data structure appropriately. This permits attaching a
ucom device to newer devices such as the Tungsten T that do not
support the Visor-style query (data structure definition gleaned
from the Linux 2.4.21 visor.c).
* Crank down UVISORBUFSIZE from 1024 to 64 to avoid a problem where
the Palm device and the USB host controller deadlock. The USB host
controller is expecting an early-end-of-transmission packet with 0
data, and the Palm doesn't send one because it's already
communicated the amount of data it's going to send in a header
(which ucom/uvisor are oblivious to). This is the problem that has
been known on the pilot-link lists as the "[Free]BSD USB problem",
but not understood.
XXX It would be better for the Palm protocol to be handled entirely
in userland via ugen, since the serial protocol abstraction isn't
really adequate for the amount of structure that's here, and the
64-byte limit is just a workaround. The pilot-link tools aren't up
to the task yet, though.
bsh