| Summary: | sys-kernel/gentoo-kernel Application for USE=experimental | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tuxine <nancy154> |
| Component: | Current packages | Assignee: | Distribution Kernel Project <dist-kernel> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | cruzki123, darkbasic, esteve.varela, hilobakho, kcelbert, mgorny, plevine457, sam, vovan |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Tuxine
2020-01-25 11:32:53 UTC
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 |
