Re: PR/50638 CVS commit: src/sys/lib/libsa

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

The following reply was made to PR bin/50638; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
To: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: PR/50638 CVS commit: src/sys/lib/libsa
Date: Sun, 17 Jan 2016 14:50:36 +0100

 On Sun, Jan 17, 2016 at 09:59:23PM +0900, Izumi Tsutsui wrote:
 > > (1) The commit message is wrong, it has been clearly demonstrated that
 > > the CRC code *does* provide obvious side-effects.
 > 
 > I just noted a test result of "booting i386 kernel without the option."
 > If you see something that is obvious, can you file a new PR?
 
 No, you said it is without side effects. That's wrong -- before bad CRC
 was detected, now it isn't.
 
 > > (2) The offered patches fixes the stated original original problem to
 > > within a small degree of the cost of uncompression.
 > 
 > I see no reason to revert it because it isn't default.
 > Most ports require "smallest or fastet" and your patch doesn't
 > provide either.
 
 No, most ports only require small enough and fast enough. Don't invent
 things just because you feel like it. The patch I offered less than
 doubles the space required for crc32 (i.e. ~100 to ~180 Bytes) and
 pushes it within a factor of 2 of the optimal results. The alternative
 might be faster, but is also significant larger (i.e. > 1KB). Even on
 martin's test, that would be less than 3s which to me seems quite
 acceptable. Your hack just removes functionality without any
 cost/benefit analysis. More importantly, it hacks around the symptoms
 and doesn't solve the real problem.
 
 > > (3) Fixing the real problem of repeated uncompression would make (2)
 > > even less a problem.
 > 
 > Once you can provide real fixes, you can apply it independently.
 > Even in that case, "no CRC check" (or zlib version) is still
 > faster than yours.
 
 If you care so much about fast, why are you compressing in first place?
 No CRC check is a significant regression and fixing the real problem
 means that the CRC check simply isn't relevant any more. Just like the
 LOAD_NOTE hacks you references in your older problems, you are just
 adding more special case hacks instead of fixing the real problem.
 That's not how NetBSD is supposed to work.
 
 Joerg