From: Nicolas Schier <nicolas.schier@linux.dev>
To: "longguang.yue" <bigclouds@163.com>
Cc: linux-kbuild@vger.kernel.org, nathan@kernel.org,
masahiroy@kernel.org, David Howells <dhowells@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
keyrings@vger.kernel.org
Subject: Re: [PATCH] Makefile: mrproper deletes signing_key.x509
Date: Mon, 11 Aug 2025 15:59:23 +0200 [thread overview]
Message-ID: <20250811-diligent-rigorous-ara-e7a9d2@l-nschier-aarch64> (raw)
In-Reply-To: <1ac1d3e3.58ad.19897d159ff.Coremail.bigclouds@163.com>
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
Cc: certs/ people
[re-ordered quote]
On Mon, Aug 11, 2025 at 02:28:56PM +0800, longguang.yue wrote:
> At 2025-08-10 04:11:57, "Nicolas Schier" <nicolas.schier@linux.dev> wrote:
> > On Sat, Aug 09, 2025 at 08:04:05PM +0800 longguang.yue wrote:
> > > deletes temporary signing_key.x509 and reserves user-defined x509.genkey
> >
> > can you elaborate the actual problem with some more details?
> >
> > certs/signing_key.x509 is removed during 'make clean' which is a dependency
> > of 'mrproper'.
> >
> > 'mrproper' is meant to remove everything that might influence a subsequent
> > call of kbuild for the sane architecture.
> >
> > Without further details I cannot see any problem here.
> >
> > Kind regards,
> > Nicolas
[...]
>
> It should not delete x509.genkey because of its exsitence in gitignore.
> Normally, users want to keep a self-defined x509.genkey, but mrproper deletes it, only default_x509.genkey is effective.
> After applying this patch, users just need to copy self-defined x509.genkey into certs directory once.
'make mrproper' is meant to prepare the source tree to be as pristine as
possible for the given architecture. This includes removal of any
configuration file(s) that influence subsequent builds. From kbuild
point of view, certs/x509.genkey is also a kind of a configuration file,
as leaving it in tree after mrproper creates different build results
compared to a build from a really pristine source tree.
Iff the certs/ maintainers think that retaining a user x509.genkey file
over a mrproper makes sense, then we should probably adjust the rule for
generating $(objtree)/certs/x509.genkey, e.g. by allowing to provide one
by environment variable.
David or David, do you have an opinion on this?
Kind regards,
Nicolas
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next parent reply other threads:[~2025-08-11 13:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250809120405.22957-1-bigclouds@163.com>
[not found] ` <aJerjQGmXXcpTtBB@fjasle.eu>
[not found] ` <1ac1d3e3.58ad.19897d159ff.Coremail.bigclouds@163.com>
2025-08-11 13:59 ` Nicolas Schier [this message]
2025-08-11 19:14 ` [PATCH] Makefile: mrproper deletes signing_key.x509 Nathan Chancellor
2025-08-12 2:22 ` longguang.yue
2025-08-12 9:31 ` David Howells
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=20250811-diligent-rigorous-ara-e7a9d2@l-nschier-aarch64 \
--to=nicolas.schier@linux.dev \
--cc=bigclouds@163.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).