[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto-vger
Subject:    Re: Userspace API proposal was: Re: [PATCH 1/1] RFC: Add CryptoAPI User Space Interface Support
From:       Evgeniy Polyakov <johnpol () 2ka ! mipt ! ru>
Date:       2008-05-14 16:09:41
Message-ID: 20080514160941.GA7419 () 2ka ! mipt ! ru
[Download RAW message or body]

Hi.

On Wed, May 14, 2008 at 08:40:43AM -0700, Loc Ho (lho@amcc.com) wrote:
> Option #2:
> 1. Use syscall with algorithm name and its associated parameters
> 2. Operation such as encrypt, decrypt, hash, and etc are operated via
> another two system call - crypto_read and crypto_write
> 3. For this option, how should one handle asynchronous operation???

No need to read/write syscall, initialization one returns a file
descriptor, which can be read/written via usual read/write calls.
It is also pollable.

> Option #3:
> 
> 1. Use syscall to create a special crypto device folder per an algorithm
> 2. A handle is returned and a crypto filesystem entry is create for that
> handle
> 3. Crypto parameter can be set based on read/write on that folder
> 4. Crypto operation will be based on file created under that folder. It
> will inherit all crypto attributes of that folder.
> 5. And etc... (See previous email)
> 6. This approach is overkill and totally unnecessary.
> 
> Does this email summary all suggested solution? If not please add to
> this list. Which one will like be accepted into the crypto tree???

Essentially it is the same as second one, but with aditional eye-candies
like simplified key management (some file in some dir written and key is
being changed).


Belive me, there will be always people, who do not like your interface,
whatever one you will create, with second or third approach such number
will be smaller, so just create what you like and prove your point is
strong. New interfaces is such a tasty ground for empty talks :)

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]