It is a layer to make it possible to have loadable PCI device drivers.
First you load (with symbols) the pcilkm module, then you can load PCI
drivers that have been compiled to work with pcilkm.
Two examples are provided. 'pcienum', the first one, is a simple
demonstration of how to use pcilkm: it is the basic skeleton of a PCI
driver, and will attach at load time to all PCI devices known to the
system.
The second example 'auich' demonstrates how simple it is to use an
existing driver as a LKM. It simply includes the code for auich(4) and
then adds the necessary pcilkm logic. However there are some drawbacks
that are described in the README file.
The algorithm used is essentially PBKDF1 from RFC 2898 but using
hmac_sha1 rather than SHA1 directly (suggested by smb@research.att.com).
* The format of the encrypted password is:
* $<tag>$<iterations>$<salt>$<digest>
*
* where:
* <tag> is "sha1"
* <iterations> is an unsigned int identifying how many rounds
* have been applied to <digest>. The number
* should vary slightly for each password to make
* it harder to generate a dictionary of
* pre-computed hashes. See crypt_sha1_iterations.
* <salt> up to 64 bytes of random data, 8 bytes is
* currently considered more than enough.
* <digest> the hashed password.
hmac.c implementes HMAC as defined in RFC 2104 and includes a unit
test for both hmac_sha1 and hmac_sha1 using a selection of the Known
Answer Tests from RFC 2202.
It is worth noting that to be FIPS compliant the hmac key (password)
should be 10-20 chars.
Added membar_store, membar_load macros.
No need to set %asi _after_ alternate space use in corresponding functions.
Enable(unifdef) casa functions for __arch64__.
is defined - this causes that nothing usable is left unless we implement
enough of C99
(there is a change in gcc-3.4 which is similar in spirit)
should fix PR lib/25930 by Dan McMahill
(I've compiled the whole KDE with this modification successfully)
non-specific EOIs. This really shouldn't matter so much, but I'm guessing
there's a strange interaction with the PALcode (possibly related to the fact
that the PALcode itself may be sending an EOI itself on some systems).
I have tested this on a Multia, and it appears to work just fine without the
INITIALLY_{ENABLED,LEVEL_TRIGGERED}() stuff now, so I'm also removing that.
As well, when we do detect some sort of an error, we should be doing a
biodone() here. Thanks to yamt for noting the missing biodone(), as
that led to discovery of the additional lossage.
