linux-kernel - Re: [RFC] LZO de/compression support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070528171115.GQ3899@stusta.de>
Date:	Mon, 28 May 2007 19:11:15 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Nitin Gupta <nitingupta910@...il.com>
Cc:	Daniel Hazelton <dhazelton@...er.net>,
	lkml <linux-kernel@...r.kernel.org>, linux-mm-cc@...top.org,
	linuxcompressed-devel@...ts.sourceforge.net,
	Andrew Morton <akpm@...ux-foundation.org>,
	Richard Purdie <richard@...nedhand.com>,
	Bret Towe <magnade@...il.com>,
	Satyam Sharma <satyam.sharma@...il.com>
Subject: Re: [RFC] LZO de/compression support - take 6

On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote:
> On 5/28/07, Adrian Bunk <bunk@...sta.de> wrote:
>...
>> - then ensure that it works correctly on all architectures and
>
> Already tested on x86, amd64, ppc (by Bret). I do not have machines
> from other archs available. Bret tested 'take 3' version but no
> changes were introduced in further revisions that could affect
> correctness - but still it will be good to have this version tested
> too. Only with inclusion in -mm and testing by much wider user base
> can make it to mainline (I suppose nobody uses -mm for production use
> anyway).
>
>>   document why your version is that much faster than the original
>>   version and why you know your optimizations have no side effects
>
> Replied in earlier mail regarding this.
>...

I have not seen any explanations:
- Why did the upstream author write the code that way?
- Why are your changes correct?
- Why do your changes allow the compiler to produce faster code?

The upstream author of the code is available - and he might be able to 
help you getting answers. No matter whether your changes are incorrect 
or correct optimizations that should go upstream, in both cases 
discussing these issues with upstream is the best solution.

And testing is nice, but if you broke some case that's outside of your 
tests you'll never notice.

> - Nitin

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/