The coreutils code is GPL and the crc module in gnulib is LGPL. I'm using the gnulib crc module in some LGPL projects. Is it wortwhile to keep the optimization GPL? I would prefer a LGPL crc module that is performant, with #ifdef-varianted support for 1) no tables at all, 2) small table like today, and 3) your bigger tables, together with support for the SSE instruction. If that makes sense and would work. Thoughts? Otherwise another approach is to keep a simple LGPL crc module and performant crc-gpl module that uses the coreutils code.
/Simon Sam Russell <sam.h.russ...@gmail.com> writes: > That sounds good. It looks like there some subtle differences anyway, the > gzip version does everything bit reversed, and while the intel paper has > constants for that there are some logic things that would have to change > (take hiword then loword instead of loword then hiword etc) > > On Mon, Oct 14, 2024, 19:05 Pádraig Brady <p...@draigbrady.com> wrote: > >> On 14/10/2024 15:53, Sam Russell wrote: >> > > For reference, coreutils' cksum uses slice by 8 unconditionally since: >> > > https://github.com/coreutils/coreutils/commit/a7533917e < >> https://github.com/coreutils/coreutils/commit/a7533917e> >> > >> > perfect, we could just copy this across then? is there a reason gnulib >> wouldn't just include coreutils as a dependency? >> >> It might be best to copy/adjust the coreutils code across to gnulib, >> then coreutils could be adjusted to use the gnulib routines. >> The crc code is under the same licence in gnulib and coreutils, so there >> should be no issue. >> >> cheers, >> Pádraig >> >>
signature.asc
Description: PGP signature
