Re: [RFC] LZO de/compression support - take 4

[Daniel Hazelton <dhazelton@enter.net>]

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