- "Shirish Pargaonkar" wrote:
> Instead of determining and allocating a char array for use during usage of
> crypto_shash_* calls, would like to instead dynamically
> allocate (and free) storage for the duration of crypto calculation
> (crypto_shash_init,
> crypto_shash_update, and crypto_shas
Instead of determining and allocating a char array for use during usage of
crypto_shash_* calls, would like to instead dynamically
allocate (and free) storage for the duration of crypto calculation
(crypto_shash_init,
crypto_shash_update, and crypto_shash_final)
But everytime I try, it results in s
- "Arnd Bergmann" wrote:
> On Friday 20 August 2010 10:45:43 Miloslav Trmač wrote:
> >
> > Major changes since the previous post:
> > * "struct nlattr"-based extensible attributes used for extensibility
> > of most operations, both for input and output attributes
>
> The API here looks ov
- "Kyle Moffett" wrote:
> On Fri, Aug 20, 2010 at 04:45, Miloslav Trmač
> wrote:
> > * ioctl(NCRIO_KEY_INIT) to allocate a key object; then generate the key
> > material inside the kernel, load a plaintext key, unwrap a key, or
> > derive a key. Similarly the key material can be copied out
On Mon, Aug 23, 2010 at 10:09 AM, Arnd Bergmann wrote:
>> This is an alternative design. There quite some reasons against that,
>> such as the auditing features. For me the main reason was that there
>> was no way to make it as fast (zero-copy) as this design, for the
>> requirements we had (int
On Sunday 22 August 2010 09:52:14 Nikos Mavrogiannopoulos wrote:
> On 08/21/2010 07:08 PM, Arnd Bergmann wrote:
> > On Friday 20 August 2010 10:45:43 Miloslav Trmač wrote:
> >> * Full compat_ioctl implementation
> > New drivers should be written to *avoid* compat_ioctl calls, using only
> > very s
