x27;s getting a bit late here, so I apologize if anything I've written
above makes particularly little sense, but hopefully I've gotten the
gist across.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Sep 6, 2010 at 15:13, Nikos Mavrogiannopoulos
wrote:
> On 09/06/2010 08:00 PM, Kyle Moffett wrote:
>>> The kernel keyring service is basically a system-wide data storage
>>> service. /dev/crypto needs a quick way to refer to short-lived,
>>> usually pr
y on process exit.
(2) Add cryptoapi hooks to automatically register keyring key types
based on the loaded cryptoapi modules.
(3) Add any necessary keyring operations for efficiently performing
zero-copy cryptoapi calls using those key types.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: se
see Documentation/keys.txt) that's being used for crypto keys for
NFSv4, AFS, etc. Can't you just add a bunch of cryptoapi key types to
that API instead?
David Howells added to CC, since I believe he wrote most of that code initially.
Cheers,
Kyle Moffett
--
To unsubscribe from this li
g boot. To be honest, the
test and integration engineer in me would like it if there were more
intensive in-kernel POST tests that could be enabled by a kernel
parameter or something for high-reliability embedded devices.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line &
ot;big win"
for the rare case, then minor changes to the memory allocator could
dramatically impact performance in a totally nondeterministic way. If
the change isn't performance-significant in the grand scheme of
things, then the use of ksize() would just be code obfuscation. On
the othe
