Re: [RFC PATCH 1/2] scripts: add kconfirm

[Nathan Chancellor]

On Tue, Apr 28, 2026 at 01:08:11PM -0600, Jonathan Corbet wrote:
> Nathan Chancellor <nathan@xxxxxxxxxx> writes:
> 
> > On Tue, Apr 28, 2026 at 01:01:29AM -0600, Jonathan Corbet wrote:
> >> Also, a nit, but I would really suggest putting it under tools/ rather
> >> than in the scripts/ dumping ground.
> >
> > As if tools/ isn't its own dumping ground? :)
> 
> It is more structured and more amenable to useful MAINTAINERS entries.

Perhaps on the structured aspect but I don't see how tools/ differs from
scripts/ with regards to MAINTAINERS entries. Yeah, Kbuild has a
scripts/ catch all but you could still add a top level folder and add
that to whatever MAINTAINERS entry you want.

> > While I can understand the desire to avoid adding more random stuff to
> > scripts/, it sets a confusing precedent because tools/ is not a part of
> > Kbuild, so I would not expect tools that would run within Kbuild to live
> > there (which this one appears to do). While there are obvious exceptions
> > such as objtool and resolve_btfids,
> 
> ...and the docs build system...

Which is a recent change, no?

> > I would like to avoid adding new
> > ones, which aligns with the comment added by Masahiro's commit
> > 6e6ef2da3a28 ("Makefile: add comment to discourage tools/* addition for
> > kernel builds"). Maybe this could be mitigated with a tools/kbuild/
> > directory or something but not sure. Just some additional input.
> 
> I don't understand that reticence.  As we build up more tools, why not
> organize them in a directory tree, perhaps called "tools", where we can
> track who's responsible for the various subtrees?

Well, the only reason I bring that up is that it will make life harder
on the Kbuild people to do treewide audits and reviews of Kbuild usage
when certain areas in tools/ use Kbuild while others don't. Obviously,
we can adapt should the general consensus want tools to live in tools/.

-- 
Cheers,
Nathan