Sorry to hijack into this thread but about having a more friendly way to
configure the kernel consistently across versions I wrote this little
utility which I sue to configure both Linux Kernel and OpenWrt
programmatically in a way which make it very very easy to upgrade versions
https://gitlab.com/g10h4ck/kconfig-utils
I have researched quite a bit into this topic because I need to deal
with kconfig based stuff in many places, and finally implemented this
which is quite sustainable even for one single person
A side note is that it seems quite dumb and frustrating to me that
KConfig doesn't support a way to configure the things programmatically
by it self, when it already support a way to do that from an interactive
menu which is probably much more cumbersome to expose a CLI to just
set/unset what is needed and report an error if something goes wrong...
(well the tool i have implemented does just that)
Cheers
Gio
On 2024-03-24 20:00, Elliott Mitchell wrote:
On Sat, Mar 23, 2024 at 07:56:01PM +0100, Stijn Segers wrote:
Op zondag 3 maart 2024 om 15:24:50 -08:00:00 schreef Elliott Mitchell
<ehem+open...@m5p.com>:
Date: Tue, 6 Feb 2024 17:16:41 -0800
Create a script for automating kernel version changes. This
generates a pair of commits which cause history to remain attached to
all versioned configuration files.
Crucially this makes `git blame` work without needing
--find-copies-harder, which is too slow for routine use. This also
updates *everything*, which greatly simplifies rebasing patches
which effect multiple devices.
Credit to Christian Marangi who knew of the technique:
<https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html>
Signed-off-by: Elliott Mitchell <ehem+open...@m5p.com>
Is there a way to bump a specific target to a new kernel with your
script? It doesn't look like it, but I might be mistaken. Would it be a
lot of work to integrate that? With the shell equivalent being merged,
I can understand any reluctance to adding this functionality, but it's
worth asking.
As originally written, no. I see significant advantages to that approach
and it really is starting to look like the best balance.
To add the ability to handle a single target, near trivial. To add the
ability to do multiple target(s), very simple. To do this efficiently,
still fairly simple.
It does seem this list has become useless for patch submission, so it has
been brought onto GitHub:
https://github.com/openwrt/openwrt/pull/14907
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
