From: Luis Chamberlain <mcgrof@kernel.org>
To: Daniel Gomez <da.gomez@samsung.com>
Cc: "kdevops@lists.linux.dev" <kdevops@lists.linux.dev>,
Pankaj Raghav <p.raghav@samsung.com>,
"gost.dev@samsung.com" <gost.dev@samsung.com>
Subject: Re: [PATCH 1/1] linux: generate tags automatically
Date: Tue, 6 Feb 2024 15:29:53 -0800 [thread overview]
Message-ID: <ZcLA8RmhIb6jPuE-@bombadil.infradead.org> (raw)
In-Reply-To: <ue3odmrpoipqrhr7xokwdoer6q3dkeztjmvlndh2r7msyxsyxn@6gomgf3rgwfb>
On Mon, Feb 05, 2024 at 12:08:52PM +0000, Daniel Gomez wrote:
> On Thu, Feb 01, 2024 at 02:28:32PM -0800, Luis Chamberlain wrote:
> >
> > We should discuss if we want or need a new choice for choosing whether
> > or not we want the a) latest and greatest or b) last boot tested / build
> > tested version. The difference being a) would likely be used to base
> > tests on which move forward, and b) allows you to do less work to test
> > the latest.
>
> I think they don't need to be exclusive. We can have the script to generate
> a) and some sort of template including b) that the script uses to generate the
> final list of options.
>
> I did a prototype of this for mcgrof-next and jlayton trees already. I can
> polish it and send a v2 for review.
Sounds good.
> I also found the script needs to be 'promoted' to the top Makefile to generate
> the kconfig and have it available when the user selects the bootlinux config
> option inside menuconfig.
>
> In addition, we probably don't want the script to run always as it delays the
> make execution.
The other option is to have features like these only if a user uses
'make dynconfig', but there seems to be a blury line between some of
these simple dynamic kconfig entries and more complex ones like the
ones used for PCI passthrough. On the one hand this one seems very
valuable at a low expense to users, but PCI passthrough is a clear
type of feature not all users want and also it exposes some low level
system details not everyone wants grep'd for.
It would seemw we just need to make a judgement call when some dynamic
kconfig is always built-in or not. This seems like a good example case
to support always being built from the start.
The only other thing I can think of / or ask is that it would be nice
for users who have an existing deployment using this to be able to
easily update the tags in case a new linux-next tag is out, or Linus
rc is out or the next stable extra version exists if one a stable kernel.
But that can be done later. The value in having something like this long
term is something like 0-day or other CI deployments using kdevops to
rev the kernel to a new one so to easily be able to automate ongoing
regression testing.
Luis
prev parent reply other threads:[~2024-02-06 23:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240201221531.3149-1-da.gomez@samsung.com>
[not found] ` <CGME20240201221534eucas1p1effd482d1e66907d3ef62effda73a59c@eucas1p1.samsung.com>
[not found] ` <20240201221531.3149-2-da.gomez@samsung.com>
[not found] ` <ZbwbEInIAzrNV4fq@bombadil.infradead.org>
2024-02-05 12:08 ` [PATCH 1/1] linux: generate tags automatically Daniel Gomez
2024-02-06 23:29 ` Luis Chamberlain [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=ZcLA8RmhIb6jPuE-@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=da.gomez@samsung.com \
--cc=gost.dev@samsung.com \
--cc=kdevops@lists.linux.dev \
--cc=p.raghav@samsung.com \
/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).