linux-kernel - Re: [PATCH] Documentation: Add patch-validator to dev-tools

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <875xfqbo5n.fsf@trenco.lwn.net>
Date: Thu, 17 Jul 2025 13:41:40 -0600
From: Jonathan Corbet <corbet@....net>
To: Ignacio Peña <ignacio.pena87@...il.com>
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Documentation: Add patch-validator to dev-tools

Ignacio Peña <ignacio.pena87@...il.com> writes:

> On Thu, Jul 17, 2025 at 09:38:00AM -0600, Jonathan Corbet wrote:
>> Interesting ... overall, we don't generally have detailed documentation
>> for out-of-tree utilities, though there isn't necessarily any reason why
>> we couldn't.  But I'm curious as to why you haven't submitted the tool
>> itself?
>
> That's a great question! I kept it external for a few reasons:
>
> First, I'm still pretty new to kernel development and wanted the freedom
> to iterate quickly as I learn what checks are actually useful. Being 
> external means I can push updates immediately when someone points out
> a new common mistake (like Greg just did with the date check!).

I would guess, though, that you would get more people pointing things
out if you were to post the tool to the list and eventually get it in.
The kernel cycle isn't *that* slow in the end...

> Second, I wrote everything in bash for simplicity, which probably isn't
> the best fit for the kernel's scripts/ directory. Plus, as Greg mentioned
> in his reply, many of these checks really belong in checkpatch.pl rather
> than a separate tool.

It wouldn't be the only bash script, certainly.

> So my plan now is to work on patches for checkpatch.pl to add the most
> useful checks there (where they belong), while keeping the workflow 
> helpers as an external toolkit.

It's your tool, you should develop it as you see fit, but keeping it
separate will make it harder to attract people to try it out.

Sending improvements to checkpatch is, of course, a good thing to do.

> Given this direction, would you prefer I withdraw this documentation 
> patch? I'm happy either way - just thought it might help other newcomers
> in the meantime, but I totally understand if you'd rather wait until
> the checks are properly integrated into checkpatch.pl.

For now, it's probably best to keep the documentation with the tool
itself; at least, that's how it seems to me.

Thanks,

jon