From: Nicolas Schier <nsc@kernel.org>
To: Sasha Levin <sashal@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Nathan Chancellor <nathan@kernel.org>,
Julian Braha <julianbraha@gmail.com>,
Lorenzo Stoakes <ljs@kernel.org>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Speed up KConfig - fix hashtable confusion
Date: Mon, 2 Nov 2026 13:50:17 +0100 [thread overview]
Message-ID: <auiHCdQEeuo2rys-@derry.ads.avm.de> (raw)
In-Reply-To: <20261102102627.526313-1-sashal@kernel.org>
On Mon, Nov 02, 2026 at 05:26:27AM -0500, Sasha Levin wrote:
> On Sun, Nov 01, 2026 at 12:08:15PM -0800, Linus Torvalds wrote:
> > The reason is that it's called just a lot, but it *really* doesn't
> > help that the scripting versions of the hashtable functions has not
> > understood the subtler issues of the hashing code that it took from
> > the kernel side, and in the process got things very very wrong.
>
> I'm not sure why we have a copy of include/linux/hashtable.h in
> scripts/, but it's silly that it has diverged slightly from what we do
> in-kernel, and now we're chasing bugs caused by that divergence.
>
> Can we instead align both back to be the same, or even use
> include/linux/hashtable.h directly from scripts/?
I think that matches Julian's proposal. For include/linux/hashtable.h,
it may be a good idea to use it directly from include/linux/, but in
general we should be careful when re-using kernel internal header files
for host tooling. I am afraid we may put a burden on changes on these
if we (mis)use them in a non-kernel context. But yes, we should
consider at least regular syncing in some way to prevent repeating
mistakes.
--
Nicolas
prev parent reply other threads:[~2026-11-02 13:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 20:08 Linus Torvalds
2026-11-01 23:44 ` Julian Braha
2026-11-02 6:53 ` Nicolas Schier
2026-11-02 9:47 ` David Laight
2026-11-02 10:26 ` Sasha Levin
2026-11-02 12:50 ` Nicolas Schier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=auiHCdQEeuo2rys-@derry.ads.avm.de \
--to=nsc@kernel.org \
--cc=julianbraha@gmail.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=nathan@kernel.org \
--cc=sashal@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®