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
