Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Loc Ho <lho@amcc.com>
Cc: Sebastian Siewior <linux-crypto@ml.breakpoint.cc>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Shasi Pulijala <spulijala@amcc.com>,
	linux-crypto@vger.kernel.org
Subject: Re: Userspace API proposal was: Re: [PATCH 1/1] RFC: Add CryptoAPI User Space Interface Support
Date: Wed, 14 May 2008 20:09:41 +0400	[thread overview]
Message-ID: <20080514160941.GA7419@2ka.mipt.ru> (raw)
In-Reply-To: <0CA0A16855646F4FA96D25A158E299D604720974@SDCEXCHANGE01.ad.amcc.com>

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

  reply	other threads:[~2008-05-14 16:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DB599F406D04E34389140B7D99C71B1B055EE51E@SDCEXCHANGE01.ad.amcc.com>
     [not found] ` <0CA0A16855646F4FA96D25A158E299D60301C29D@SDCEXCHANGE01.ad.amcc.com>
     [not found]   ` <DB599F406D04E34389140B7D99C71B1B055EE6B2@SDCEXCHANGE01.ad.amcc.com>
2008-05-14  0:00     ` [PATCH 1/1] RFC: Add CryptoAPI User Space Interface Support Loc Ho
2008-05-14 10:32       ` Sebastian Siewior
2008-05-14 11:03         ` Herbert Xu
2008-05-14 11:57           ` Userspace API proposal was: " Sebastian Siewior
2008-05-14 12:18             ` Evgeniy Polyakov
2008-05-14 15:40               ` Loc Ho
2008-05-14 16:09                 ` Evgeniy Polyakov [this message]
2008-05-15 20:16                   ` Linux CryptoAPI Userspace API proposal Loc Ho
2008-05-20  4:00                     ` Herbert Xu
2008-06-04 21:33                       ` Loc Ho
2008-05-14 15:04           ` [PATCH 1/1] RFC: Add CryptoAPI User Space Interface Support Loc Ho
2008-05-14 16:01             ` Herbert Xu
2008-05-14 11:25       ` Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080514160941.GA7419@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=herbert@gondor.apana.org.au \
    --cc=lho@amcc.com \
    --cc=linux-crypto@ml.breakpoint.cc \
    --cc=linux-crypto@vger.kernel.org \
    --cc=spulijala@amcc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox