On Mon, Nov 18, 2024 at 09:58:09PM +0000, Sami Tolvanen wrote: > Hi, > > On Sat, Nov 16, 2024 at 9:09 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > > > On Thu, Nov 14, 2024 at 2:54 AM Sami Tolvanen <samitolvanen@xxxxxxxxxx> wrote: > > > > > > Hi, > > > > > > On Mon, Nov 11, 2024 at 8:06 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Oct 31, 2024 at 2:01 AM Sami Tolvanen <samitolvanen@xxxxxxxxxx> wrote: > > > > > > > > > > To avoid duplication between host programs, move the crc32 code to a > > > > > shared header file. > > > > > > > > > > > > Only the motivation to use this long table is to keep compatibility > > > > between genksyms and gendwarfksyms. > > > > I do not think this should be exposed to other programs. > > > > > > > > > > > > If you avoid the code duplication, you can do > > > > > > > > // scripts/gendwarfksyms/crc.c > > > > #include "../genksyms/crc.c" > > > > > > Sure, that sounds reasonable. I'll change this in the next version. > > > > > > BTW, is it necessary to share the same crc function > > between genksyms and gendwarfksyms? > > > > If CONFIG_GENKSYMS and CONFIG_GENDWARFKSYMS > > were able to produce the same CRC, it would be a good motivation > > to share the same function. > > However, as far as I tested, gendwarfksyms generates different CRC values. crc32() is operating on different data, right? CONFIG_GENDWARFKSYMS computes a crc of the DWARF data, whereas CONFIG_GENKSYMS computes a crc of a magic string from ... the source code, right? Hence the crcs will never match? > > When a distro migrates to CONFIG_GENDWARFKSYMS, > > the new kernel cannot load old modules built with CONFIG_GENKSYMS. > > No, it's not necessary to use the exact same function, this was just > to avoid adding more external dependencies. > > > So, there is no need to share the old code. > > Another solution might be to use crc32() provided by zlib, for example. > > It requires another external library, but this already depends on > > libdw and libelf. > > Makes sense. I'll switch to the zlib implementation in v6. > > > > > > Suggested-by: Petr Pavlu <petr.pavlu@xxxxxxxx> > > > > > Signed-off-by: Sami Tolvanen <samitolvanen@xxxxxxxxxx> > > > > > Acked-by: Neal Gompa <neal@xxxxxxxxx> > > > > > > > > Does this Ack add any value? > > > > > > > > Acked-by is meaningful only when it is given by someone who > > > > maintains the relevant area or has established a reputation. > > > > > > > > $ git grep "Neal Gompa" > > > > $ git shortlog -n -s | grep "Neal Gompa" > > > > 2 Neal Gompa > > > > > > > > His Ack feels more like "I like it" rather than a qualified endorsement. > > > > > > Like Neal explained, an Ack from a potential user of this feature > > > seemed relevant, but if you don't think it's meaningful, I can > > > certainly drop it. > > > > Tested-by is more suitable if he wants to leave something. > > Ack. Neal, I'll drop the acks from v6, but if you end up testing that > series, please feel free to add your Tested-by. Just my 2 cents, but it seems rude to me to *remove* an Ack from an existing patchset on the grounds that person doesn't appear often in the kernel log. "We won't hire you for this entry level job because you don't have experience" etc. Also, wouldn't Neal be one of the people shepherding this change into distro kernels? He seems to show up somewhat frequently in the Fedora and SUSE ecosystems. Is the problem here that you all think "Acked-by" isn't appropriate from someone who isn't a subsystem maintainer, but the kernel doesn't seem to have a tag for "downstream consumer of this change says they're willing to put their name on the line for this"? Maybe should we go full Parks and Rec: Not-Against-You-On-This-One: Neal Gompa <neal@xxxxxxxxx> --D
