linux-kernel - Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page

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: <472515f8-2737-4444-9eb6-1f6a0650f26b@gtucker.io>
Date: Thu, 22 Jan 2026 15:25:35 +0100
From: Guillaume Tucker <gtucker@...cker.io>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, David Gow <davidgow@...gle.com>,
 Onur Özkan <work@...rozkan.dev>,
 Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, linux-kbuild@...r.kernel.org,
 automated-testing@...ts.yoctoproject.org, workflows@...r.kernel.org,
 llvm@...ts.linux.dev
Subject: Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page

Hi Nathan,

On 22/01/2026 05:55, Nathan Chancellor wrote:
> On Wed, Jan 21, 2026 at 10:55:53AM +0100, Guillaume Tucker wrote:
>> Feel free to make these tweaks now, or we might wait a bit to see if
>> others have more feedback with further changes and I can send a v4.
> 
> How about this? Send a v4 with:
> 
> 1. An initial MAINTAINERS entry addition in patch 1 for
>    scripts/container like I suggested earlier and scripts/container
>    explicitly added to the KERNEL BUILD section so that Nicolas and I
>    are included for handling patches.
> 
> 2. Add the Documentation to the aforementioned MAINTAINERS entry as part
>    of patch 2.
> 
> 3. Either encorporate my suggested change for preferring podman over
>    docker with the appropriate changes elsewhere inte the patch set like
>    you mentioned or explore checking for the docker alias explicitly.
>    Entirely up to you timewise, as long as it results in Nicolas's
>    environment working, since I don't think that will be too uncommon.
> 
> 4. Encorporate any other feedback that you feel is appropriate at this
>    stage (if there is any low hanging fruit).

Sounds great, I just sent a v4 as described above.  I've kept any
extra features out for now to avoid introducing new issues and added
a workaround for out-of-tree builds in the docs.  Hopefully this will
solve Nicolas' use cases and work for others too.

> Then we can apply it so that folks can start using it in -next for
> testing and validation. After that, you can start thinking of things you
> would want to work on for future merge windows from the list you already
> started, as I know how that goes when working on a new tool :)

Thanks again for all the reviews, it'll be good to see what people
make of it!  Meanwhile I'll keep working on further improvements,
starting with the limitations mentioned in the docs.

Cheers,
Guillaume