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.