The new ebuild from gentoo-kernel has generated approval and joy among many users. In this context a request: It would be very nice if you could integrate "IUSE=experimental" from genpatches into your ebuild. With these two flags "savedconfig" and "experimental" we have all the possibilities that gentoo-sources also offers. Thank you
Do you actually use any of the features provided by experimental patches? I skipped them because they didn't seem very useful for generic configs. OTOH, I don't really understand why they are optional given that AFAICS they don't change anything by default.
Hi all. I know some ppl loving CONFIG_MNATIVE. Despite it's obviously not generic feature, having ability for transparent migration to portage-management kernel updates with exactly same functionality (achieved by savedconfig) is nice, imo.
Hello, We're using CONFIG_MNATIVE from the experimental patches and ZSTD compression. Yes, I agree that they are optional, but if you provide 'savedconfig' feature, IMHO 'experimental' would be useful as well and they're maintained for 'gentoo-sources' anyway.
Chiming in since I dropped the GCC patch in my /etc/portage/patches and a snippet to set CONFIG_MZEN=y in my /etc/kernel/config.d. The main usecase of this kernel to me is avoiding the whole kernel upgrade song and dance, and just having it upgrade overnight with everything else without intervention. I got sick of missing kernel drivers for peripherals when I need to use them, and digging through the kernel config for them, not to mention the times I've had performance issues due to some kernel config I didn't know, so running a "generic", portage-managed kernel relieves me of the duty and worry, despite only running it on one machine. I use `-march=znver` in my make.conf, so why wouldn't I apply it to the kernel as well?
I started using sys-kernel/gentoo-kernel a month ago. Having manually built the kernel from gentoo-sources for the last 16 years, I think auto-building the kernel without having to deal with ugly hooks is one of this distro's greatest advancements in years. I have always used the experimental patch. It adds a small but measurable gain (see https://github.com/graysky2/kernel_gcc_patch) and -march=native adds cache-line heuristics, I believe. (In reply to Michał Górny from comment #1) > Do you actually use any of the features provided by experimental patches? I > skipped them because they didn't seem very useful for generic configs. > OTOH, I don't really understand why they are optional given that AFAICS they > don't change anything by default. So I'll ask naively, why not merge gentoo-sources into gentoo-kernel? You can add "generic" USE flags for a generic build, "source" USE flag for full source installation, etc... Why maintain the two separately when they're so logically similar?
I too use CONFIG_MNATIVE and would like to take advantage of the easy handling of the kernel and external module rebuilding gentoo-kernel has. For now I just patch the ebuild to add it, but it'd be nice not to have to do it myself.
> Having manually built the kernel from gentoo-sources for the last 16 years, I think auto-building the kernel without having to deal with ugly hooks is one of this distro's greatest advancements in years. I HAVE to quote this, so valuable. While I don't use the kernel_compiler_patch (because I'm on ppc64) I would definitely use it on x86.
(In reply to Kyle Elbert from comment #6) > I too use CONFIG_MNATIVE and would like to take advantage of the easy > handling of the kernel and external module rebuilding gentoo-kernel has. > > For now I just patch the ebuild to add it, but it'd be nice not to have to > do it myself. Rather use /etc/portage/patches/sys-kernel/gentoo-kernel - you'll only need to update the patch when jumping between major versions, or when upstream updates their patch https://github.com/graysky2/kernel_compiler_patch
I can step up and implement it, in case no one is against the change
Came here to request it. "experimental" patches is the only thing keeping me from moving to gentoo-kernel. It would be great convenience to have it in repo instead of manual hacks.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4189bc96fac6b9e5e314ea5997c7fdb2ce1804f1 commit 4189bc96fac6b9e5e314ea5997c7fdb2ce1804f1 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2024-08-31 08:38:53 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2024-08-31 09:47:29 +0000 sys-kernel/gentoo-kernel: add IUSE=experimental If the comments on the bug report are any indication then this is a popular requested feature. Adding it is relatively simple. Note that this does not actually change the .config, enabling any of these new options should be done via savedconfig or /etc/kernel/config.d. Closes: https://bugs.gentoo.org/706294 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/38350 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> sys-kernel/gentoo-kernel/Manifest | 2 ++ sys-kernel/gentoo-kernel/gentoo-kernel-6.10.7.ebuild | 5 ++++- sys-kernel/gentoo-kernel/gentoo-kernel-6.6.48.ebuild | 5 ++++- sys-kernel/gentoo-kernel/metadata.xml | 3 +++ 4 files changed, 13 insertions(+), 2 deletions(-)
(In reply to Peter Levine from comment #5) > So I'll ask naively, why not merge gentoo-sources into gentoo-kernel? You > can add "generic" USE flags for a generic build, "source" USE flag for full > source installation, etc... Why maintain the two separately when they're so > logically similar? This would significantly delay the release of gentoo-sources. Currently new versions of gentoo-sources are always released first, then once we have a confirmed working config we release gentoo-kernel and build gentoo-kernel-bin. If we were to merge this then gentoo-sources users would have to wait until the final step of the gentoo-kernel(-bin) release process. For major releases that could be several weeks.
(In reply to Andrew Nowa Ammerlaan from comment #12) > (In reply to Peter Levine from comment #5) I would also argue they're not logically similar. They're fundamentally different approaches to building and configuring a kernel. Both have their strengths/weaknesses. gentoo-sources, for example, is a lot easier for iterating on a config (partly as it's less indirection, partly as you aren't forced to do clean builds).
