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

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

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