AF_INET6 wildcard listening socket. heavily documented in ip6(4).
net.inet6.ip6.bindv6only defines default value. default is 1.
"options INET6_BINDV6ONLY" removes any code fragment that supports
IPV6_BINDV6ONLY == 0 case (not defopt'ed as use of this is rare).
which we claim we've seen the loop up at least once so
that we don't hang forever coming up. Add in the basics
for MI target mode stuff. Force the outer layers to deal
with a FCP response coming back that has a CHECK CONDITION
but no sense data.
- fire up a new thread for parity re-writes, copybacks, and reconstructs.
The ioctl's which trigger these actions now return immediately.
- add progress accounting for the above actions.
- minor rototillage of rf_netbsdkintf.c to deal with all of the above.
succeeds, note that we now are valid.
- Don't attempt to try and run initialize element status from interrupt level-
we don't really support that yet. Also, key more correctly off of ASC/ASCQ
instead of just the sense key.
- Make the practice of doing an INITIALIZE ELEMENT STATUS automatically when
we get params (from chopen time even) a policy decision that is not the
default for now- this can be a dangerous practice as well as time consuming.
It's dangerous in that you can have a hung open when all you really want
to do is do a read of parameters- and parameters, including slot status,
are perfectly fine to read even before an INITIALIZE ELEMENT STATUS is
done- all the elements whos status your read are going to be marked with
an exception- so leave it up to the application to decide how important
this is.
allow the user to set and use the internal baud rate generator
fix the transmission ring logic to support more than 1 frame per interrupt
add autodetection of the base clock frequency.
cleanup the receive ring logic
support dynamically resizing the low-water mark on the fifo in response
to buffer underruns on transmit.
This is not strictly necessary, as
- at least for the Ricoh chip in the A3000 and A4000, as those chips' Y10
registers happily continue to count up from 0xA if manually incremented
past 0x9.
- the Amiga ROMs and "setclock" commands seem to interpret 0xA 0x? like
200?, etc.
However,
- the Amiga setclock writes the modulo 10 value into the chips
- the chip docs of both chips, including the Y2K information of their
manufacturers, only refer to the range 0-9
- the chips increment from 9 to 0
So we better conform to this, to avoid unpleasant surprises.
leo