Hi,
On Wed, Sep 29, 2010 at 05:24:27PM +0200, Nikos Mavrogiannopoulos wrote:
> poll can also be seen as a generic way to check for IO, so if having
> two ioctls, one for submitting and one for retrieving, poll can also be
> used there.
>
> What I don't like with read() and write() is that it come
On 09/29/2010 04:59 PM, Phil Sutter wrote:
> Hi,
>
> On Wed, Sep 29, 2010 at 03:56:46PM +0200, Nikos Mavrogiannopoulos wrote:
>> I like the implementation and the idea. A question would be why use
>> read()/write()
>> instead say of new ioctls (e.g. CIOCCRYPT_ASYNC)?
>
> The motivation behind rea
Hi,
On Wed, Sep 29, 2010 at 03:56:46PM +0200, Nikos Mavrogiannopoulos wrote:
> I like the implementation and the idea. A question would be why use
> read()/write()
> instead say of new ioctls (e.g. CIOCCRYPT_ASYNC)?
The motivation behind read() and write() is being able to fetch or push
more than
On Tue, Sep 28, 2010 at 1:58 PM, Phil Sutter wrote:
> Hi!
> Please do not apply this patch as is - this is just meant for review,
> therefore
> I didn't bother removing debug output and dead code.
> IMO, a bigger rewrite of the internal routines in cryptodev_main.c is needed
> in
> order to supp
Still ugly as hell (and therefore TODO):
- no real error handling
- having to pass task_struct and mm_struct from the calling process
around
- need to copy the IV right at write() time (copy_from_user seems to
work in process context only)
- ugly branching using is_compat_task() to stay compati
