public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Artem B. Bityuckiy" <dedekind@yandex.ru>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Artem B. Bityuckiy" <dedekind@infradead.org>,
	dwmw2@infradead.org, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org, jmorris@redhat.com,
	svenning@post5.tele.dk,
	YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Subject: Re: [RFC] CryptoAPI & Compression
Date: Sun, 03 Apr 2005 16:01:19 +0400	[thread overview]
Message-ID: <424FDB0F.6000304@yandex.ru> (raw)
In-Reply-To: <20050403114704.GC21255@gondor.apana.org.au>



Herbert Xu wrote:
> On Sun, Apr 03, 2005 at 03:41:07PM +0400, Artem B. Bityuckiy wrote:
> 
>>I also wonder, does it at all correct to use negative windowBits in 
>>crypto API? I mean, if windowBits is negative, zlib doesn't produce the 
> 
> 
> It's absolutely correct for IPComp.  For other uses it may or may not
> be correct.
I've looked through RFC-2394 quickly, but didn't found any mention about 
non-complient zstreams. I suppose they must be complient by default. 
Although I'm far not an expert in the area.

> For instance for JFFS2 it's absolutely incorrect since it breaks
> compatibility.  Incidentally, JFFS should create a new compression
> type that doesn't include the zlib header so that we don't need the
> head-skipping speed hack.
Anyway, in JFFS2 we may do that "hack" before calling pcompress(), so it 
isn't big problem.

> Yes, I'd love to see a patch that makes windowBits configurable in
> crypto/deflate.c.
I wonder, do we really want this?

Imagine we have 100 different compressors, and each is differently 
configurable. It may make cryptoAPI messy. May be it is better to stand 
that user must use deflate (and the other 99 compressors) directly if he 
wants something not standard/compliant?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

  parent reply	other threads:[~2005-04-03 12:01 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-25 16:08 [RFC] CryptoAPI & Compression Artem B. Bityuckiy
2005-03-26  4:44 ` Herbert Xu
2005-03-26 11:32   ` Artem B. Bityuckiy
2005-03-28 17:22   ` Artem B. Bityuckiy
2005-03-29 10:35     ` Herbert Xu
2005-03-29 11:55       ` Artem B. Bityuckiy
2005-03-31  2:19         ` Herbert Xu
2005-03-31 10:43           ` Artem B. Bityuckiy
2005-03-31 11:11             ` Herbert Xu
2005-04-01 14:36               ` Artem B. Bityuckiy
2005-04-01 14:44                 ` David Woodhouse
2005-04-01 14:57                   ` Artem B. Bityuckiy
2005-04-01 15:05                     ` David Woodhouse
2005-04-01 15:22                       ` Artem B. Bityuckiy
2005-04-01 15:33                         ` Jörn Engel
2005-04-03  8:47                           ` Artem B. Bityuckiy
2005-04-01 15:23                 ` Herbert Xu
2005-04-01 15:41                   ` Artem B. Bityuckiy
2005-04-01 22:13                     ` Herbert Xu
2005-04-03  8:22                       ` Artem B. Bityuckiy
2005-04-03  8:27                         ` Artem B. Bityuckiy
2005-04-03  8:29                         ` Artem B. Bityuckiy
2005-04-03  8:44                         ` Herbert Xu
2005-04-03  8:59                           ` Artem B. Bityuckiy
2005-04-03  9:30                             ` Herbert Xu
2005-04-03  9:45                               ` Artem B. Bityuckiy
2005-04-03 10:00                                 ` Herbert Xu
2005-04-03 10:06                                   ` David Woodhouse
2005-04-03 10:17                                     ` Herbert Xu
2005-04-03 10:23                                       ` Artem B. Bityuckiy
2005-04-03 11:42                                         ` Herbert Xu
2005-04-03 15:24                                           ` Artem B. Bityuckiy
2005-04-03 11:19                                       ` David Woodhouse
2005-04-03 11:40                                         ` Herbert Xu
     [not found]                                           ` <4250175D.5070704@yandex.ru>
     [not found]                                             ` <20050403213207.GA24462@gondor.apana.org.au>
2005-04-18 15:09                                               ` Artem B. Bityuckiy
2005-04-19  9:25                                                 ` Herbert Xu
2005-04-19 12:51                                                   ` Artem B. Bityuckiy
2005-04-19 22:10                                                     ` Herbert Xu
2005-04-03 10:19                                   ` Artem B. Bityuckiy
2005-04-03  9:20                           ` Artem B. Bityuckiy
2005-03-31  9:51     ` Herbert Xu
2005-04-03 11:41       ` Artem B. Bityuckiy
2005-04-03 11:47         ` Herbert Xu
2005-04-03 11:53           ` Artem B. Bityuckiy
2005-04-03 12:00             ` Herbert Xu
2005-04-03 12:01           ` Artem B. Bityuckiy [this message]
2005-04-03 12:07             ` Herbert Xu
2005-04-03 12:18               ` Artem B. Bityuckiy

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=424FDB0F.6000304@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=dedekind@infradead.org \
    --cc=dwmw2@infradead.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jmorris@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=svenning@post5.tele.dk \
    --cc=yoshfuji@linux-ipv6.org \
    /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