On 5/24/07, Satyam Sharma <[email protected]> wrote:
Hmm. The wrappers would clearly be inline, but if we want a common
low-level decompress function, we'd also need to introduce the "if (safe &&)"
kind of tests for those differently-defined macros which could impact
performance (for the _unsafe variant only, isn't it). By how much is the
question, and whether we really care to avoid duplicating 50 lines of code
to take that hit on the unsafe function (or vice versa).
All this just to avoid that symlink? What is so wrong with that? Yes,
the ugliest thing is some additions to top-level Makefile but I think
this the reason those prepare{1,2,3....} targets were meant for.
> All I will add is that after the amendment I made, the ugliness in my
> patchset is confined to one file now and I still think its the better
> approach to take.
>
> My main concerns with this patch are that:
> * from the security point of view its not tried and tested code
> * I'm not 100% confident in what Nitin has done with the code from a
> buffer overflow/security PoV
> * its not tested on many architectures
> * the performance implications of the rewrite are unknown
Right, it needs testing (for correctness and robustness). But that
shouldn't be too difficult -- Nitin, you could just write up a simple test
module that others can use with your patch to do testing on their
arch's ... the more this gets tested, the better chances it's got.
Mailed 'compressed-test' module along with usage to Bret (CC'ed to
you, Richard, linux-kernel). This makes it very easy to test this LZO
code.
Thanks for comments.
- Nitin
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
