src/sys/opencrypto/cryptodev.h, branch release/5.3.0_cvs FreeBSD source tree This commit was manufactured by cvs2svn to create tag 2004-11-04T19:12:42+00:00 cvs2svn cvs2svn@FreeBSD.org 2004-11-04T19:12:42+00:00 3f86d8a2ea3f3265afaa1fd263b0004c5c000e69 'RELENG_5_3_0_RELEASE'. This commit was manufactured to restore the state of the 5.3-RELEASE image. 
'RELENG_5_3_0_RELEASE'.

This commit was manufactured to restore the state of the 5.3-RELEASE image.
Add CRD_F_KEY_EXPLICIT which allows the key to be changed per 2004-02-02T17:06:34+00:00 Poul-Henning Kamp phk@FreeBSD.org 2004-02-02T17:06:34+00:00 c740ae4b464b7be48525c960012becb868982c9b operation, just like it was possible to change the IV. Currently supported on Hifn and software engines only. Approved by: sam@ 
operation, just like it was possible to change the IV.

Currently supported on Hifn and software engines only.

Approved by:	sam@
Push m_apply() and m_getptr() up into the colleciton of standard mbuf 2003-12-15T21:49:41+00:00 Bruce M Simpson bms@FreeBSD.org 2003-12-15T21:49:41+00:00 37621fd5d93015b59e08fc1278cbabfbf393fa7b routines, and purge them from opencrypto. Reviewed by: sam Obtained from: NetBSD Sponsored by: spc.org 
routines, and purge them from opencrypto.

Reviewed by:	sam
Obtained from:	NetBSD
Sponsored by:	spc.org
consolidate callback optimization check in one location by adding a flag 2003-06-30T05:09:32+00:00 Sam Leffler sam@FreeBSD.org 2003-06-30T05:09:32+00:00 d8409aaf6e683996e179b67ebb387777104595cb for crypto operations that indicates the crypto code should do the check in crypto_done MFC after: 1 day 
for crypto operations that indicates the crypto code should do the check
in crypto_done

MFC after:	1 day
Add support to eliminate a context switch per crypto op when using the 2003-06-27T20:07:10+00:00 Sam Leffler sam@FreeBSD.org 2003-06-27T20:07:10+00:00 07d0c94a4621a47d1b967e5c7cc7c17f26812f95 software crypto device: o record crypto device capabilities in each session id o add a capability that indicates if the crypto driver operates synchronously o tag the software crypto driver as operating synchronously This commit also introduces crypto session id macros that cleanup their construction and querying. 
software crypto device:

o record crypto device capabilities in each session id
o add a capability that indicates if the crypto driver operates synchronously
o tag the software crypto driver as operating synchronously

This commit also introduces crypto session id macros that cleanup their
construction and querying.
Flush my local cache of cryto subsystem fixes: 2003-06-02T23:28:06+00:00 Sam Leffler sam@FreeBSD.org 2003-06-02T23:28:06+00:00 3569ae7f667f89001ebda6fcb5dfd76253cd1cc4 o add a ``done'' flag for crypto operations; this is set when the operation completes and is intended for callers to check operations that may complete ``prematurely'' because of direct callbacks o close a race for operations where the crypto driver returns ERESTART: we need to hold the q lock to insure the blocked state for the driver and any driver-private state is consistent; otherwise drivers may take an interrupt and notify the crypto subsystem that it can unblock the driver but operations will be left queued and never be processed o close a race in /dev/crypto where operations can complete before the caller can sleep waiting for the callback: use a per-session mutex and the new done flag to handle this o correct crypto_dispatch's handling of operations where the driver returns ERESTART: the return value must be zero and not ERESTART, otherwise the caller may free the crypto request despite it being queued for later handling (this typically results in a later panic) o change crypto mutex ``names'' so witness printouts and the like are more meaningful 
o add a ``done'' flag for crypto operations; this is set when the operation
  completes and is intended for callers to check operations that may complete
  ``prematurely'' because of direct callbacks
o close a race for operations where the crypto driver returns ERESTART: we
  need to hold the q lock to insure the blocked state for the driver and any
  driver-private state is consistent; otherwise drivers may take an interrupt
  and notify the crypto subsystem that it can unblock the driver but operations
  will be left queued and never be processed
o close a race in /dev/crypto where operations can complete before the caller
  can sleep waiting for the callback: use a per-session mutex and the new done
  flag to handle this
o correct crypto_dispatch's handling of operations where the driver returns
  ERESTART: the return value must be zero and not ERESTART, otherwise the
  caller may free the crypto request despite it being queued for later handling
  (this typically results in a later panic)
o change crypto mutex ``names'' so witness printouts and the like are more
  meaningful
o add a CRYPTO_F_CBIMM flag to symmetric ops to indicate the callback 2003-02-23T07:25:48+00:00 Sam Leffler sam@FreeBSD.org 2003-02-23T07:25:48+00:00 eb73a605cd2213db74496820092c4564ca4977c7 should be done in crypto_done rather than in the callback thread o use this flag to mark operations from /dev/crypto since the callback routine just does a wakeup; this eliminates the last unneeded ctx switch o change CRYPTO_F_NODELAY to CRYPTO_F_BATCH with an inverted meaning so "0" becomes the default/desired setting (needed for user-mode compatibility with openbsd) o change crypto_dispatch to honor CRYPTO_F_BATCH instead of always dispatching immediately o remove uses of CRYPTO_F_NODELAY o define COP_F_BATCH for ops submitted through /dev/crypto and pass this on to the op that is submitted Similar changes and more eventually coming for asymmetric ops. MFC if re gives approval. 
  should be done in crypto_done rather than in the callback thread
o use this flag to mark operations from /dev/crypto since the callback
  routine just does a wakeup; this eliminates the last unneeded ctx switch
o change CRYPTO_F_NODELAY to CRYPTO_F_BATCH with an inverted meaning
  so "0" becomes the default/desired setting (needed for user-mode
  compatibility with openbsd)
o change crypto_dispatch to honor CRYPTO_F_BATCH instead of always
  dispatching immediately
o remove uses of CRYPTO_F_NODELAY
o define COP_F_BATCH for ops submitted through /dev/crypto and pass
  this on to the op that is submitted

Similar changes and more eventually coming for asymmetric ops.

MFC if re gives approval.
MFS: crypto timing support; purge usercrypto sysctl (just don't config 2003-01-03T06:16:59+00:00 Sam Leffler sam@FreeBSD.org 2003-01-03T06:16:59+00:00 7d1853ee0eb8664f3e3b03649a181776e267f316 cryptodev or kldunload cryptodev module); crypto statistcs; remove unused alloctype field from crypto op to offset addition of the performance time stamp Supported by: Vernier Networks 
cryptodev or kldunload cryptodev module); crypto statistcs; remove
unused alloctype field from crypto op to offset addition of the
performance time stamp

Supported by:	Vernier Networks
remove CIOGSSESSION (get software session); it was added only for testing 2002-10-07T18:37:31+00:00 Sam Leffler sam@FreeBSD.org 2002-10-07T18:37:31+00:00 b4c408e0fe423a1afb1c36176e8d37e77226426b 






In-kernel crypto framework derived from openbsd.  This facility provides
2002-10-04T20:31:23+00:00

Sam Leffler
sam@FreeBSD.org

2002-10-04T20:31:23+00:00

091d81d134ca70cc39425028bc815f8cfb068d4b

a consistent interface to h/w and s/w crypto algorithms for use by the
kernel and (for h/w at least) by user-mode apps.  Access for user-level
code is through a /dev/crypto device that'll eventually be used by openssl
to (potentially) accelerate many applications.  Coming soon is an IPsec
that makes use of this service to accelerate ESP, AH, and IPCOMP protocols.

Included here is the "core" crypto support, /dev/crypto driver, various
crypto algorithms that are not already present in the KAME crypto area,
and support routines used by crypto device drivers.

Obtained from:	openbsd





a consistent interface to h/w and s/w crypto algorithms for use by the
kernel and (for h/w at least) by user-mode apps.  Access for user-level
code is through a /dev/crypto device that'll eventually be used by openssl
to (potentially) accelerate many applications.  Coming soon is an IPsec
that makes use of this service to accelerate ESP, AH, and IPCOMP protocols.

Included here is the "core" crypto support, /dev/crypto driver, various
crypto algorithms that are not already present in the KAME crypto area,
and support routines used by crypto device drivers.

Obtained from:	openbsd