From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6002914A60C for ; Tue, 19 Nov 2024 21:38:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732052297; cv=none; b=Xlbuv8Uy0yWdC9Mfmh4sOr0ez+AzxhtRgz+0QJsEaKeTPNjTfAKgWgIyEPCYjTqL7CaTVaUKNiOyWBEJPwnZwmbA+HZ8+6KPjpMQ1CjxSeuio+x/I+WcYG2Hy6ULr2PYE2He6KRHH7KG9NqKgzP1BnEkdIAIuO7bqsHibIRXvtw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732052297; c=relaxed/simple; bh=Zd2QB6z5/nO/5q32zOMmJULah0pVbTKjUr9QlGKD+V4=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=uALHS6ATqPd0dVCes62hSojgvZqkkje9zjbYnRixVKRaJM5l946PS+tsmWEzqkQe+eqoR380b7H+ySUg3Gg4aNiVfPXG3r10I/uPDSEU6bEkSms+vVepiwIaWSrJFruBxofyRjER7wG47VkLvjgoq2AaFFqQ4zNj7dprOAckhh0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=riOe9kTP; arc=none smtp.client-ip=209.85.208.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="riOe9kTP" Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5cfc264b8b6so16965a12.0 for ; Tue, 19 Nov 2024 13:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732052293; x=1732657093; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KHaLTJLv2qMAaXUVhzeSonG7VLA1CIIMmtCZ7ax6TDw=; b=riOe9kTPt2Z4CGEcbASPouoXwaiHTuSrqylopYOwFm2ooik3fCWEN5wQ7CFc4BpHi1 Z09pMsnCRkkEtbwCNA309i5p3KGGGAAPvse4M5K6q8EC8W1Prq6kyI12w0J/ruevidYC lJTWrfCwgZu/Vo8WjsutqlgwruYRy3MFheM1PCrWzoAHiBcsG//++wjvnf/U4QRdPMTr 1RjAlbdldv64NIOOrSdf1eOu3jMnYQQSbdWPIVo1x95LEWAeIiel/z8cIBaPrXtY66wz iaKmmmsINe2jLKDJGhpqkTbFfkGe5EHL5MHcMmwNBbD6x7xNSXJbWMbJEA6qS1Ml6uet CneQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732052293; x=1732657093; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KHaLTJLv2qMAaXUVhzeSonG7VLA1CIIMmtCZ7ax6TDw=; b=aJcNBrrwS6omNu4f49oUP4VJLQV9gTbRAEHyuoGNJYhov8nwi2HZWx/mKESRfarfjj NtWMwFZS7J6ql6v+pyHYSuVEMtABOsjPrRlKnyXoDJsfgMpLUidgaUlWZzG5GSpanan7 /Fw9icl8m6wNBZnvLbtX+MideHDoPHaApylRNRuEZ218f3ub5vOPLqjH/DFMgHIFwP8Y CiCgicUzvj2sjFMqkZUqep0Gye0lQyj80+HbzmEZWhlu3oEqaJ2i6VPhrADfxjPX6s/i D1dZvTrEcZYwW54IsZtHiCULvsRD4R9BGh8zswA+RokvhWDapVU+s6pUPDQeaJUKoQQw sUAw== X-Forwarded-Encrypted: i=1; AJvYcCWyl2n095UhtpQAubUa9ty5Zl+9AnZGklhfBM0hyIMMTbMJE4YjRhIluykBH6D1Dr/CfXcH+jbBUrnyXvyKVw==@vger.kernel.org X-Gm-Message-State: AOJu0YwTCQqweB7VixijMQN1Zc1R6QhRoUUaURas+nqo6vVcXVQQgQDo 1ii9af21Jqvj/ubyY2Gp3k4tohLvdQaCOfrb797L/sbGI4WdyBUMI95cy0VHzc+329DLXKqd39A s44gmd14NNH0kuCPOZMR5w0cJ17o1D84NdhcU X-Gm-Gg: ASbGncv1kEfLSpLXkIGqWX1JtlH9DtGG/YDKS6g8p0Yz04bH/qEDECJy03+0/q3I6a0 MAtQ8/p14oG2YO3T0GQQPzx+ruH0VQxMmpaxiI/jH6D4xyFJy3j1YZ8qsgQ2+Ig== X-Google-Smtp-Source: AGHT+IEu1TvsuhTaj4Y+Akxvvr6wi40qDULQBNFY0mTnIT/+3AaCJ0gDLLAcrNpIwNcwmpaw1b+off/DTHI6qwyqUP8= X-Received: by 2002:a05:6402:b3a:b0:5cf:f20c:bdf0 with SMTP id 4fb4d7f45d1cf-5cff4314190mr20664a12.4.1732052292462; Tue, 19 Nov 2024 13:38:12 -0800 (PST) Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20241030170106.1501763-21-samitolvanen@google.com> <20241030170106.1501763-22-samitolvanen@google.com> <20241119204829.GA1926309@frogsfrogsfrogs> In-Reply-To: <20241119204829.GA1926309@frogsfrogsfrogs> From: Sami Tolvanen Date: Tue, 19 Nov 2024 13:37:35 -0800 Message-ID: Subject: Re: [PATCH v5 01/19] scripts: move genksyms crc32 implementation to a common include To: "Darrick J. Wong" , Greg Kroah-Hartman Cc: Masahiro Yamada , Luis Chamberlain , Miguel Ojeda , Matthew Maurer , Alex Gaynor , Gary Guo , Petr Pavlu , Daniel Gomez , Neal Gompa , Hector Martin , Janne Grunau , Miroslav Benes , Asahi Linux , Sedat Dilek , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Darrick, On Tue, Nov 19, 2024 at 12:48=E2=80=AFPM Darrick J. Wong wrote: > > On Mon, Nov 18, 2024 at 09:58:09PM +0000, Sami Tolvanen wrote: > > Hi, > > > > On Sat, Nov 16, 2024 at 9:09=E2=80=AFAM Masahiro Yamada wrote: > > > > > > On Thu, Nov 14, 2024 at 2:54=E2=80=AFAM Sami Tolvanen wrote: > > > > > > > > Hi, > > > > > > > > On Mon, Nov 11, 2024 at 8:06=E2=80=AFPM Masahiro Yamada wrote: > > > > > > > > > > On Thu, Oct 31, 2024 at 2:01=E2=80=AFAM Sami Tolvanen 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 compatibili= ty > > > > > 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 va= lues. > > 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? Correct, they will never match. > > > > > > Suggested-by: Petr Pavlu > > > > > > Signed-off-by: Sami Tolvanen > > > > > > Acked-by: Neal Gompa > > > > > > > > > > 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 endor= sement. > > > > > > > > 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"? I certainly appreciate Neal's input, but I don't have a strong opinion about which tag is appropriate. The documentation seems to suggest that Acked-by is _often_ used by maintainers and focuses on that use case, but doesn't explicitly rule out other folks acking patches either: https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-b= y-cc-and-co-developed-by Perhaps Greg, or someone else with more experience with the nuances of acking, can clarify the policy in this situation? Sami