a vector of indices into the cfdata table to specify potential parents,
record the interface attributes that devices have and add a new "parent
spec" structure which lists the iattr, as well as optionally listing
specific parent device instances.
See:
http://mail-index.netbsd.org/tech-kern/2002/09/25/0014.html
...for a detailed description.
While here, const poison some things, as suggested by Matt Thomas.
it actually fixes a problem:
When /bin/sh gets a SIGSEGV, its signal handler calls brk and the offending
instruction is retried. Usually it gets another SIGSEGV, and things loops
until it pases without the SIGSEGV. This is the normal mode of operation, and
it can be reproduced on IRIX by a 10kB shell script starting by echo /*
However... the signal handler checks for BADVADDR in the saved registers
in struct sigcontext. If it does not find it, it gives up and exit instead
of retrying. Filling the field enables us to carry on normal operation
(which is to get dozens of SIGSEGV) instead of getting a failure at the
first SIGSEGV.
Setup sequence obtained from Krups OFW with some CyberPro-specific
magic from Linux driver. The driver still has a lot of hardcoded
stuff, but it is useful enough to bring up wscons on netwinder.
XXX: Proper console attachment needs to be written (the driver was
originally developed on sparc, where our approach to attaching console
is totally different).
Caveat emptor!
hunting for an MSS option to clamp. The previous code assumed that at least
one more byte of options (such as a TCPOPT_EOL) would follow the MSS
option; now, we allow the MSS option to end on the last byte of the
TCP header.
Packets have been observed "in the wild" with a TCP header length of
'6' (24 bytes.. 20 bytes fixed header, 4 bytes options) with a 4-byte
MSS option exactly filling the 4 bytes of options payload and no
following TCPOPT_EOL.
RFC793 is quite explicit that the EOL byte:
" .. need only be used if the end of the options would not
otherwise coincide with the end of the TCP header."
bpf_mtap() gets called with not-well-initialized mbuf, so we need to go through
it without touching m->m_pkthdr.len and such. it's part of our bpf_mtap() API
(at least today).
darrenr