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
instead of polling for them.
Unfortunately we cannot enable it yet because it panics the kernel
somewhere in kqueue.
Submitted by: Stefan Farfeleder <e0026813@stud3.tuwien.ac.at>
This will be removed when new versions of syscalls sigreturn()
and sigaction() are added (mini is working on this but is in
the middle of a move).
This should fix the problem of cvsupd dying.
SCSI disks are too square pegs for the round holes in both of these.
And since atapi-cd has clearly shown that there are better acccess
models for CD media than trying to pretend to be a classical disk,
we stop the masquerade rather than patch up the costume.
But do implement the DIOCGMEDIASIZE and DIOCGSECTORSIZE so it will
be possible to manually attach to GEOM, should some the need arise.
Ideally, this driver should do media-detection and call make_dev()
when a CD is inserted and destroy_dev() when it is removed, this
would allow our future devd(8) to automount etc etc but coding that
takes SCSI-clue beyond anything I posses.
Tested on: sparc64
This reduces the size of GENERIC's text space by 73999 bytes (about 2%).
The bloat is from approximately 3437 strings longer than 31 characters
being padded to a 32-byte boundary.
some deliberation the name "libbsdxml" was chosen since it conveys the two
most important attributes: "Private to FreeBSD" and "XML".
Add a skeleton man-page to give the credit and point for further
documentation. (If somebody wants to write a true mdoc manpage for
this I am sure both the eXpat people and I will be grateful).
(Still not connected to the build)
around limitations in the ia64 kernel stack handling code. Basically
preallocate a bunch of threads (and hence kstacks) while contigmalloc()
still works, and never free them back to the general memory pool. After
the system has been running for a while, contigmalloc() eventually fails
at a critical momemt and panics the system.
