Rename kernel names

[ghost]

Please rename the kernel names To gcc march So its easier to install cpu specific kernel using

sudo pacman -S linux-tkg-bmq-$(gcc -c -Q -march=native --help=target | grep march |head -1|awk '{print $2}'){,-headers}

From chaotic-aur repo

For example

Please rename. linux-tkg-bmq-zen To linux-tkg-bmq-znver1

And so on

According to its march

[gardotd426]

How does this make anything any easier? It's already CPU-specific

[PedroHLC]

@gardotd426 How does this make anything any easier? It's already CPU-specific

I think what librewish wants is that people don't have to search which of the available names is the CPU they own. They could just run a script and retrieve the exact package's name.

This also seems to be stronger related to chaotic-aur builds, but we don't generate these names. They come from TkG's scrips, and I believe these rely upon upstream...

[Tk-Glitch]

linux-tkg doesn't include any march string in the package name by default. It's unique to chaotic-aur, but you can mimic it through the custom naming option in .cfg. Replacing the current internal names would make the options far less user friendly and is not desirable. I could add some alternative name for the script to accept for a given march, I guess, to allow for both the user-friendly name and the march flag.

Of course, that won't have any effect as is and would require chaotic-aur to use that naming, which might be a problem/huge annoyance.

[BillFleming]

Have you considered an enhancement that just affects the name of the output package file for different names from an auto-build script? When I used either of the existing name change options they affected the package in ways I definitely didn't want.

[Tk-Glitch]

No and I honestly don't see the point (nor do I see the point of building kernels with -march=native btw, considering the virtually non-measurable gains). I have added the existing options begrudgingly due to insisting users but I don't agree with them so I have had no reason to consider adding layers of complexity for something I see as undesirable.

[BillFleming]

There are other reasons to spit out packages with different names than just changing the march. For example it is becoming clear that we may need to ship different fixes and patches for iommu separately for intel/vs amd kernel builds. Then also you might have different scheduler options for different HW. Or you may just want to generate a bunch of kernels all at once with different settings, then test them later. Of course making a config to change the name might be silly when you can just rename the files in a build script.

[Tk-Glitch]

For a single user making different testing or vm-dedicated versions etc., the current custom pkname option works and imho fits well. For heavier needs (such as that a bunch of kernels all at once case) it might need some additional fluff. Nothing a small additional script wouldn't be able to do (or depending on the needs, arguably smart usage of option variables used in the .cfg). If there is a solution to satisfy everyone that doesn't involve double the existing code for all linux-tkg, I'm open to suggestions.

[gardotd426]

Yeah, it would be nice to be able to keep two kernels of the same version but with completely different customizations. Like, I have a linux512-tkg-cfs build with the ACS override patch that I named linux512-tkg-cfs-iommu, but because of that I can't install a regular linux512-tkg-cfs build because it conflicts with the headers because they both want to use /usr/lib/modules/5.12.5-158-tkg-cfs.

Is there no easy way to have the path for the headers inherit the custom pkgbase? Like /usr/lib/modules/5.12.5-158-tkg-cfs-iommu?

[AdelKS]

I have an idea that may work for everyone here, be able to set your own kernel tail: instead of linux512-tkg-pds-llvm you can set it manually to linux512-tkg-MyAwesomeKernel or... linux512-tkg-zen3-O3, and I believe the resulting package won't conflict with the other linux512 packages with different names. This is already possible for non-Arch through the _kernel_localversion config variable, it can be extended to Arch. What do you think of this ?

[Tk-Glitch]

This is already possible on Arch with the _custom_pkgbase option.

# If you want to bypass the stock naming scheme and enforce something else (example : "linux") - Useful for some bootloaders requiring manual entry editing on each release.
# !!! It will also change pkgname - If you don't explicitely need this, don't use it !!!
_custom_pkgbase=""

[AdelKS]

The issue with _custom_pkgbase is that even the kernel version is lost in the kernel name although it can be added manually. True that.

[Tk-Glitch]

I agree the option is kinda too powerful, but it was requested that way. You can make it dynamic using config variables such as $_processor_opt if desired. The stock string is linux"${_basever}"-tkg-"${_cpusched}"${_compiler_name} if you want to keep it and just add more stuff to it.

[AdelKS]

I think the perfect solution for what's asked here is to enable a config option that goes:

_custom_pkgtail="[sched][compiler]"

which spits out the usual -tkg-pds-llvm. But people would be able to edit it to

_custom_pkgtail="[sched][compiler][march][rr_interval][compile_opt]"

which would spit out something like -tkg-pds-llvm-zen3-rr4-O3

[AdelKS]

I agree the option is kinda too powerful, but it was requested that way. You can make it dynamic using config variables such as $_processor_opt if desired. The stock string is linux"${_basever}"-tkg-"${_cpusched}"${_compiler_name} if you want to keep it and just add more stuff to it.

Absolutely, that should work exactly as is asked here. It adds some work for the user because unfortunately, some of those variables are only filled after running the script. The user would need to fill them up by hand in the config file and any mistake needs a recompile.

[Tk-Glitch]

Indeed

[AdelKS]

If there is a way to do something like this in customization.cfg

_custom_pkgtail='${_cpusched}${_compiler_name}'

Notice that we used '...' so the variables are not replaced by their values. Then only actually interpret the string and replace the variables after user input, then this would be an elegant thing :thinking: So one can put any variable he wants, like _processor_opt (and also even undocumented ones, at his own risk). But that would need to put everything in BIG_UGLY_FROGMINER for Arch :laughing:

[Tk-Glitch]

Alternatively we could add options to the existing _kernel_localversion/_custom_pkgbase (we should think about merging those into one btw), like if the variable is set to append_marchopt (or something), it'll use default + append _processor_opt.

This is one of the most popular usages for those along with removing versioning, so we could just add those two and leave more complex naming schemes to the actual advanced users.

[AdelKS]

(we should think about merging those into one btw)

I thought about it, but _custom_pkgbase doesn't do the same thing as _kernel_localversion which only touches the tail. I actually started some work on a PR to actually make these two complementary :

• _custom_pkgbase: sets the beginning of the package name, i.e. linux512, if left empty it takes the default naming scheme. I actually don't know how and haven't researched if we can override the entirety of the kernel name on non-Arch :thinking: I am not even sure it's possible. So it may be an Arch-specific option
• _custom_pkgtail : sets the end of the package name, the -tkg-pds-llvm, it can be set to say it must be empty so _custom_pkgbase works as it used to.

So we get the kernel name as being ${_custom_pkgbase}+${_custom_pkgtail}.

Now with _custom_pkgtail

1. can be made to follow what you suggested
   • "" (empty): nothing
   • "default": defaults
   • "append_march": appends march
   • we can add more and more stuff here, since we will be asked to add more options for sure (that the kernel has been LTO'd, O3, etc...), or also just append whatever option is not recognized
2. Or it can be made to follow the variable replacement scheme

   _custom_pkgtail='-${_cpusched}${_compiler_name}'

What do you think of this grand plan ? rewrites the entirety of linux-tkg Nah I think it's not a big change, is it ? xD

Side note: If we can set _custom_pkgbase for non-Arch, we can actually go with only one config variable

_kernel_name='linux${_basever}-tkg-${_cpusched}${_compiler_name}'

with the variable replacement trick. But I am ready to bet that make rpm-pkg and make deb-pkg are not that flexible.

[binarydepth]

No and I honestly don't see the point (nor do I see the point of building kernels with -march=native btw, considering the virtually non-measurable gains). I have added the existing options begrudgingly due to insisting users but I don't agree with them so I have had no reason to consider adding layers of complexity for something I see as undesirable.

JIC Check my benchmarks here, Manghud offers more info at the end of logging, dunno if you have tested against that 0.1% lows.

[AdelKS]

JIC Check my benchmarks here, Manghud offers more info at the end of logging, dunno if you have tested against that 0.1% lows.

Those benchmarks do not seem to highlight any difference between two different CPU micro-architectures, e.g. generic vs skylake or something. Or did I miss it ?

[gentuwu]

This is actually something I have been having issues with. Regardless of what I input in those fields, nothing changes... I'd appreciate any help greatly!