[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200705251255.22600.dhazelton@enter.net>
Date: Fri, 25 May 2007 12:55:21 -0400
From: Daniel Hazelton <dhazelton@...er.net>
To: Richard Purdie <richard@...nedhand.com>
Cc: Satyam Sharma <satyam.sharma@...il.com>,
Nitin Gupta <nitingupta910@...il.com>,
linux-kernel@...r.kernel.org, linux-mm-cc@...top.org,
Andrew Morton <akpm@...ux-foundation.org>,
Andrey Panin <pazke@...pac.ru>, Bret Towe <magnade@...il.com>,
Michael-Luke Jones <mlj28@....ac.uk>
Subject: Re: [RFC] LZO de/compression support - take 4
On Friday 25 May 2007 09:38:24 Richard Purdie wrote:
<snip>
> > > I am however still strongly of the opinion that we should just use the
> > > version in -mm (which is my latest version).
> >
> > Right, if the difference is anything >10%, code cleanup does lose
> > its attractiveness.
>
> Agreed, and I still have the security and maintainability concerns. Add
> them all together and its more unattractive.
I can understand the security concerns, but since none of the bounds checking
has been removed there shouldn't be any difference from a security
viewpoint. I have maintained the code to a MUD server at one point - I can
guarantee that it had a lot more code than the LZO code - and it was so
highly customized that no patches to the core code from anywhere *outside*
that games "coders" would apply. This means that every one of those patches
had to be done manually - sure, it was a massive PITA - but it was worth it.
In other words - yes, it will make maintaining the code harder, but the fact
that the code matches the kernels style and is "lightweight" compared to the
original userspace code *and* Richards "miniLZO" should mitigate this.
As to the performance - I can see absolutely no reason why the minimal version
shouldn't perform the same (or better). The kernel codes memset and memcpy
routines have been heavily tested *and* optimized over the years and moving
from macro's to inline functions shouldn't have impacted performance at all.
I will be testing the two code bases myself in a little bit - I'm more than a
little paranoid and don't like the idea of trusting anyone with a "competing
project" for all testing.
DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists