Messages in this thread | | | Date | Fri, 25 May 2007 10:42:54 +0000 | From | Pavel Machek <> | Subject | Re: [RFC] LZO de/compression support - take 3 |
| |
Hi!
> Perhaps you have opinion of maintaining diffability with > original LZO > code which differs from mine. Since the code is now just > ~500 lines it > should be fair enough to have major overhauls for sake > of clean > KernelStyle(tm) code. It shouldn't be that hard to > verify this small > code for bugs that might have crept in during porting > work. As regard > to keeping up with future LZO versions, hm.... that will > be hard - but > I don't think algorithm itself will change and > optimizations can > always be done separately in this fork. > > > > >> I'd agree with the proposed renaming. In fact I'd > >suggest that the unsafe > >> APIs just be removed - it's hard to imagine a > >situation in which they're OK > >> to be used in the kernel. > > > >The compressed cache code might be one exception since > >it does the > >compression itself and shouldn't get corrupted. If it > >does get > >corrupted, you have bigger problems. > > > > Yes. Compressed Caching is one of cases where compressed > data cannot > get magically corrupted. Hence, there is no need to go > for the 'safe' > version. There might be other such cases too, so > removing 'unsafe' > version is not good.
What is the performance difference between safe and unsafe version?
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |