lkml.org 
[lkml]   [2007]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2007-05-26 11:33    [W:0.763 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site