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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
