From: "Nitin Gupta" <nitingupta910@gmail.com>
To: "Richard Purdie" <richard@openedhand.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Michael-Luke Jones" <mlj28@cam.ac.uk>,
linux-kernel@vger.kernel.org, linux-mm-cc@laptop.org
Subject: Re: [RFC] LZO de/compression support - take 3
Date: Thu, 24 May 2007 09:34:12 +0530 [thread overview]
Message-ID: <4cefeab80705232104n54b23b9bi8b5db8e6a6dd1c0a@mail.gmail.com> (raw)
In-Reply-To: <1179938960.5864.26.camel@localhost.localdomain>
On 5/23/07, Richard Purdie <richard@openedhand.com> wrote:
> On Wed, 2007-05-23 at 09:16 -0700, Andrew Morton wrote:
> > On Wed, 23 May 2007 19:51:44 +0530 "Nitin Gupta" <nitingupta910@gmail.com> wrote:
> > > On 5/23/07, Michael-Luke Jones <mlj28@cam.ac.uk> wrote:
>
> > If so, it was quite inappropriate that a filesystem be using the unsafe
> > version.
>
> Yes, I'll give you a patch to change the resier4 code in -mm then (if
> its not already been changed).
Richard, are you planning to use this patch for LZO or your own port?
Can we decide on a Final Unified(tm) version of LZO port and then
patch up reiser4 or whatever to use that Ultimate LZO instead?
Can you please look into this (take 3) version on LZO patch posted and
we can edit/add/remove things from this to unify our effort - there is
no point in this duplication.
Perhaps you have opinion of maintaining diffability with original LZO
code which differs from mine. Since the code is now just ~500 lines it
should be fair enough to have major overhauls for sake of clean
KernelStyle(tm) code. It shouldn't be that hard to verify this small
code for bugs that might have crept in during porting work. As regard
to keeping up with future LZO versions, hm.... that will be hard - but
I don't think algorithm itself will change and optimizations can
always be done separately in this fork.
>
> > I'd agree with the proposed renaming. In fact I'd suggest that the unsafe
> > APIs just be removed - it's hard to imagine a situation in which they're OK
> > to be used in the kernel.
>
> The compressed cache code might be one exception since it does the
> compression itself and shouldn't get corrupted. If it does get
> corrupted, you have bigger problems.
>
Yes. Compressed Caching is one of cases where compressed data cannot
get magically corrupted. Hence, there is no need to go for the 'safe'
version. There might be other such cases too, so removing 'unsafe'
version is not good.
Ok, I will rename 'unsafe' version as such (as suggested by Michael).
Cheers,
Nitin
next prev parent reply other threads:[~2007-05-24 4:04 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-23 8:27 Nitin Gupta
2007-05-23 10:53 ` Michael-Luke Jones
2007-05-23 11:39 ` Nitin Gupta
2007-05-23 13:57 ` Michael-Luke Jones
2007-05-23 14:03 ` Nitin Gupta
2007-05-23 14:10 ` Michael-Luke Jones
2007-05-23 14:21 ` Nitin Gupta
2007-05-23 14:33 ` Michael-Luke Jones
2007-05-24 22:41 ` Richard Purdie
2007-05-24 22:54 ` Andrew Morton
2007-05-24 23:00 ` Richard Purdie
2007-05-23 16:16 ` Andrew Morton
2007-05-23 16:49 ` Richard Purdie
2007-05-24 4:04 ` Nitin Gupta [this message]
2007-05-25 10:42 ` Pavel Machek
2007-05-26 10:23 ` Michael-Luke Jones
2007-05-26 11:17 ` Nitin Gupta
2007-05-23 14:50 ` Bret Towe
2007-05-24 13:48 ` Nitin Gupta
2007-05-25 2:38 ` Bret Towe
2007-05-25 5:10 ` Nitin Gupta
2007-05-25 17:02 ` Bret Towe
2007-05-25 17:33 ` Nitin Gupta
2007-05-26 11:30 ` Nitin Gupta
2007-05-27 3:39 ` Bret Towe
2007-05-23 19:34 ` Satyam Sharma
2007-05-24 4:37 ` Nitin Gupta
2007-05-24 10:49 ` Satyam Sharma
2007-05-24 8:25 ` Richard Purdie
2007-05-24 11:07 ` Satyam Sharma
2007-05-24 14:29 ` Nitin Gupta
2007-05-24 19:12 ` Satyam Sharma
2007-05-24 14:20 ` Nitin Gupta
2007-05-24 20:09 ` Satyam Sharma
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=4cefeab80705232104n54b23b9bi8b5db8e6a6dd1c0a@mail.gmail.com \
--to=nitingupta910@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm-cc@laptop.org \
--cc=mlj28@cam.ac.uk \
--cc=richard@openedhand.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
all inboxes | Powered by JetHome®