On Mon, 2007-06-04 at 23:56 +0530, Nitin Gupta wrote: > Yes there might still be problems - that is why I posted as RFC. I got > useful comments and the code is improving. Going for such fork might > be pain initially but IMHO its worth it. My idea for this 'fork' is > not just clean-ups but potential optimizations that such cleanups > usually bring along. I do not think there will be major overhauls in > such mature de/compression implementations so I believe its okay to go > for such 'fork' for sake of cleaner and perhaps faster code.
If you want to make cleaner and faster code, why not work on LZO upstream directly? I'm sure the LZO author would welcome the speedups, just as much as the kernel would. If they're accepted into LZO, I'm nearly certain the kernel will accept them and if the kernel code is as I've proposed, upgrading is straightforward too. Working with "upstream" is often harder but ultimately much more rewarding. > Again, I am working on improving the code as per feedback. This is > what I expect from RFC. Many people raised concerns regarding > bloatware in your patch too, including me. And there are concerns against your patches including: * endian issues * alignment issues * potential security holes * unexplained code generation differences * difficulty of upgrading Compared to the style/bloat issue, I'd say that's a fair compromise. Regards, Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
