full, kick the binary blob to force it to complete any pending tx
completions.
- In the watchdog routine, only reset the chip if the blob doesn't complete
any pending tx completions rather than requiring it to complete all of
the pending tx completions.
Submitted by: Nathan Whitehorn <nathanw@uchicago.edu>
MFC after: 2 weeks
a defensive programming measure.
Note that whilst these members are not used by the ip_output()
path, we are passing an instance of struct ip_moptions here
which is declared on the stack (which could be considered a
bad thing).
ip_output() does not consume struct ip_moptions, but in case it
does in future, declare an in_multi vector on the stack too to
behave more like ip_findmoptions() does.
scripts. These scripts handle vnode backed md(4) devices.
Old ramdisk{,-own} scripts will stay a bit in CVS to allow some time for
migration since variable names have changed (ramdisk_* -> mdconfig_*).
Two new variables have been introduced to be able to populate the md(4)
device once it has been mounted (mdconfig_*_files and mdconfig_*_cmd).
Use should be as easy as:
mdconfig_md0="-t malloc -s 10m"
mdconfig_md1="-t vnode -f /var/foo.img"
See rc.conf(5) for more information and description of the additional
variables.
Approved by: cperciva
RPC_MAXDATASIZE was introduced. This is believed to have been debugging
code committed accidentally, although I've been unable to reach the
committer to confirm this. The effect was to limit the size of RPCs on
TCP and UDP to 9k, well below the default protocol limits in the libc
rpc code. This change simply removes these introduced limits, falling
back on the libc definitions.
PR: 88856
Reported by: Keith Bostic <bostic at sleepycat dot com>
Testing by: Susan LoVerso <sue at loverso dot southborough dot ma dot us>
Reveiwed by: cel, rees
Review timeout: alfred, mbr
MFC after: 2 weeks
lnc(4) on PC98 and i386. The ISA front-end supports the same non-PNP
network cards as lnc(4) did and additionally a couple of PNP ones.
Like lnc(4), the C-bus front-end of le(4) only supports C-NET(98)S
and is untested due to lack of such hardware, but given that's it's
based on the respective lnc(4) and not too different from the ISA
front-end it should be highly likely to work.
- Remove the descriptions of le(4), which where converted from lnc(4),
from sys/i386/conf/NOTES and sys/pc98/conf/NOTES as there's a common
one in sys/conf/NOTES.
entry to the PCI NICs section so it's in the same spot in all GENERIC
config files.
- Add a note to the description of pcn(4) informing that is has precedence
over le(4).
or SHA512, the blocksize is 128 bytes, not 64 bytes as anywhere else.
The bug also exists in NetBSD, OpenBSD and various other independed
implementations I look at.
- We cannot decide which hash function to use for HMAC based on the key
length, because any HMAC function can use any key length.
To fix it split CRYPTO_SHA2_HMAC into three algorithm:
CRYPTO_SHA2_256_HMAC, CRYPTO_SHA2_384_HMAC and CRYPTO_SHA2_512_HMAC.
Those names are consistent with OpenBSD's naming.
- Remove authsize field from auth_hash structure.
- Allow consumer to define size of hash he wants to receive.
This allows to use HMAC not only for IPsec, where 96 bits MAC is requested.
The size of requested MAC is defined at newsession time in the cri_mlen
field - when 0, entire MAC will be returned.
- Add swcr_authprepare() function which prepares authentication key.
- Allow to provide key for every authentication operation, not only at
newsession time by honoring CRD_F_KEY_EXPLICIT flag.
- Make giving key at newsession time optional - don't try to operate on it
if its NULL.
- Extend COPYBACK()/COPYDATA() macros to handle CRYPTO_BUF_CONTIG buffer
type as well.
- Accept CRYPTO_BUF_IOV buffer type in swcr_authcompute() as we have
cuio_apply() now.
- 16 bits for key length (SW_klen) is more than enough.
Reviewed by: sam
crypto_invoke(). This allows to serve multiple crypto requests in
parallel and not bached requests are served lock-less.
Drivers should not depend on the queue lock beeing held around
crypto_invoke() and if they do, that's an error in the driver - it
should do its own synchronization.
- Don't forget to wakeup the crypto thread when new requests is
queued and only if both symmetric and asymmetric queues are empty.
- Symmetric requests use sessions and there is no way driver can
disappear when there is an active session, so we don't need to check
this, but assert this. This is also safe to not use the driver lock
in this case.
- Assymetric requests don't use sessions, so don't check the driver
in crypto_kinvoke().
- Protect assymetric operation with the driver lock, because if there
is no symmetric session, driver can disappear.
- Don't send assymetric request to the driver if it is marked as
blocked.
- Add an XXX comment, because I don't think migration to another driver
is safe when there are pending requests using freed session.
- Remove 'hint' argument from crypto_kinvoke(), as it serves no purpose.
- Don't hold the driver lock around kprocess method call, instead use
cc_koperations to track number of in-progress requests.
- Cleanup register/unregister code a bit.
- Other small simplifications and cleanups.
Reviewed by: sam
- Implement CUIO_SKIP() macro which is only responsible for skipping the given
number of bytes from iovec list. This allows to avoid duplicating the same
code in three functions.
Reviewed by: sam
actually destroyed. Also move call to knlist_init() into tapcreate(). This
should fix panic described in kern/95357.
PR: kern/95357
No response from: freebsd-current@
MFC after: 3 days
Peter Fellgett's wildcard recipe:
Into a clean dish, place the dry ingredients and add the
liquids until the right consistency is obtained. Turn out
into suitable containers and cook until done.
use this ioctl to obtain the list of HCI nodes. User-space application
is expected to preallocate 'ng_btsocket_hci_raw_node_list_names' structure
and set limit in 'num_nodes' field. The 'nodes' field should be allocated
as well and it should have space for at least 'num_nodes' elements.
The SIOC_HCI_RAW_NODE_LIST_NAMES should be issued on bound raw HCI socket.
It does not really really matter what HCI name the socket is bound to, as
long as it is not empty.
MFC after: 1 week
