On Monday 04 June 2007 16:45:55 Richard Purdie wrote: > On Mon, 2007-06-04 at 13:37 -0400, Daniel Hazelton wrote: > > Yes - most of that work, IIRC, is related to the alignment issues that > > Herr Oberhumer noted. As it stands, the alternative does work well for a > > large number of the platforms that the kernel supports. With a little > > Kconfig magic it could be made available *only* for those platforms that > > it currently supports. Then people can help work on the alignment issues > > - possibly by providing platform conditional code. > > My patch was actually written with ARM machines in mind and has been > extremely well tested on it. A version which doesn't run on ARM is not > acceptable. Its also ironic that "platform conditional code" is what a > lot of that bloat you're so keen to remove is about.
Done in a very poor manner. > > I'm not familiar with the zlib code, but it was included a long time ago > > - since zlib was included I'm pretty certain that if it had been proposed > > today it would have been NACK'd for the style violations and bloat. > > Adrian's covered this. I also know how hard updating something like zlib > is (I was the last person to do it). I do agree. I have looked over the zlib code and it is very involved - I, personally, would not like to have to maintain it if I couldn't easily diff it against userspace. > > You can take the time to produce a patch and spread FUD about the speed > > of a competing patches code but you don't have the time to work on fixing > > a cleaner implementation? I'll admit that actually working on fixing > > problems in code can take more time, but still - the time taken for those > > pursuits *could* have been spent actually working on fixing the problems. > > I *have* spent some time on it. > > My speed comments were actually pretty positive. Yes, I screwed up one > of the benchmarks (as have others proving its easily done) but I did > admit to it. My others were fair comment and some issues were addressed > as a result (but not all). I've looked back over the entire spread of the messages, both from before I wrote that quick&dirty benchmark and after. Maintainability is a good thing to aim for, however the style used to achieve the complete cross-platform mobility could be handled a lot cleaner - give me a few days to really study the LZO code and I'll see if I can't reach a middle-ground - code that is easy to maintain (and diff against userspace) as well as being stripped to its core and very cleanly implemented. I can't promise results, but I figure I'm at fault for really starting this current spate of flames so I should at least take responsibility and do something to try and put them out. What I can say, at this point, is that a lot of my changes will be in making the code comply to kernel-style in a manner *similar* to how Nitin has done it - collapse redundant code together, replace open-coded blocks with calls to library functions, etc... > I'm going to stop here. I don't agree with the rest of your email and > you've a distorted view of whats been said. Hindsight is sometimes too perfect. I should have returned to the early posts for clarity before making a lot of the comments I did. It shames me to admit that I've made such a nasty mistake and made myself seem like nothing more than a common troll. Apologetically, 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/
