v1.97.0

[cyring]

@ich777 , @inglor , anyone

Hello,

This version is about ARM AArch64 and still the latest x86_64 models

The compilation has evolved.
The binaries corefreqk.ko corefreqd and corefreq-cli are now compiled into the build sub-directory
Makefile is taking care to create the build temporary directory.
Makefile is detecting one of the two machine x86_64 or aarch64
If useful an uninstall recipe has been added
Parallel build is more efficient. One can simply run make -j

Apart a merged master branche, I have not create a release yet until packaging has integrated those changes.

Best regards
Cyril

[inglor]

@cyring updated the -git package, waiting for the release.

[inglor]

It should work now.

[inglor]

@cyring please cut a release to update stable package.

[cyring]

I will. This is almost ready with a safe arm64 port

[cyring]

Is it ok for you if I release a 1.97.1-rc1 ?

[inglor]

I can wait for 1.97.1 don't mind :)

[cyring]

It should work now.

This has worked perfectly
Thank you.

[cyring]

Since kernel 6.8rc1 and its mandatory -Wmissing-prototypes, all non static functions in corefreqk.c compile with a warning.
Surprisingly in-tree drivers do not warn for the same issue.

gcc is v13

[cyring]

@inglor

Well you can honor $(CFLAGS) $(LDFLAGS) and not override them

In develop branch, commit 8815697 tries to make use of CFLAGS and LDFLAGS in the Makefile

I was expecting my ArchLinux CFLAGS LDFLAGS from /etc/makepkg.conf to be taken into account during the CoreFreq build but they remain blank.
I believe makepkg.conf exists for the sole purpose of the packaging and not for manual compilation. Do you agree ?

EDIT: in addition to that, I now have a regression with CentOS 3 where rewriting CFLAGS seems forbidden

Due to numerous regressions, I have rollback to the original Makefile.
The ArchLinux attempt is left here

[inglor]

If you try to build with makepkg then it's using /etc/makepkg.conf. If you are using the devtools with clean chroot it's using /usr/share/devtools/makepkg.conf.d/x86_64.conf. You are not suppose to change the /usr/share/devtools/makepkg.conf.d/x86_64.conf one as it's used from devs to build packages.

[cyring]

Thanks I will have a look into /usr/share/devtools/makepkg.conf.d/x86_64.conf
Although I don't know if it is particular to ArchLinux ?

Makefile has to remain compatible with all Distributions I came across so far.
That's my challenge.

[inglor]

Understood and it's probably OK to keep the patch maintained in my side :)

[cyring]

You may have noticed that a CI is now helping to track build regressions. You will find results in repository tab actions

I still continue to build by hand in various VM, with workstations and an Orange-Pi 5+

Nightly status of 1.97.0

• x86_64

Distribution	Kernel	Compiler	Status	Source
Chimera	6.1.60	clang 17.0.5	passed	VM
openSUSE	5.14.6	gcc 11.2.1	passed	VM
debian 9	4.9.0	gcc 6.3.0	passed	VM
ClearLinux	6.6.1	gcc 13.2.1	passed	VM
CentOS 8.4	4.18.0	gcc 8.4.1	passed	VM
CentOS 7	3.10.0	gcc 4.8.5	passed	VM
ArchLinux	6.7.4	gcc 13.2.1	passed	AMD Ryzen 3950X
ArchLinux	6.3.5	gcc 13.1.1	passed	Intel Xeon W3690
Buildroot	6.7.4	gcc 13.2.1	failed	ArchLinux

• aarch64

Distribution	Kernel	Compiler	Status	Source
Debian 11	5.10.0	gcc 10.2.1	passed	VM[Neoverse N2]
Debian 12	5.10.160	gcc 12.2.0	passed	RK3588[Cortex A76 + A55]

[cyring]

Since commit fc9f470 is fixed the ratios display for hybrid processors. This concerns generations Alder Lake and afterwards ; the big.LITTLE architectures of ARM v8, v9 like RK3588 below

Can anyone with Intel Hybrid post such screenshot to let me verify ?

[bubbleguuum]

I'm the openSUSE package maintainer and working on an updated RPM .spec file for when 1.97.0 is released.

It's working fine with very minor modifications, but a few observations:

• in the Makefile, install invocations could use its -D option to create the target directory path if necessary. When installing in a sandbox compile environment, $PREFIX/bin and $PREFIX/lib/systemd/system may not exist. This can trivially be fixed in whatever package script creating these directories before invoking make, but it would still be nice if the Makefile created these.
• I also wished CFLAGS was honored. Speaking of which, the default optimized CFLAGS on openSUSE Tumbleweed are -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g. Can you tell if any of them is problematic, especially link time optimization (-flto) ?

[cyring]

Hello,

in the Makefile, install invocations could use its -D option to create the target directory path if necessary. When installing in a sandbox compile environment, $PREFIX/bin and $PREFIX/lib/systemd/system may not exist. This can trivially be fixed in whatever package script creating these directories before invoking make, but it would still be nice if the Makefile created these.

I will try but I was expecting a Systemd distribution to already be set up with such directories.
For this, I have to make non regression tests among all distributions and down to kernel 3

I also wished CFLAGS was honored.

Indeed. ArchLinux is also claiming the same.
Passing optimization level, but not -O0 in kernel module, is the issue.

Can you tell if any of them is problematic, especially link time optimization (-flto) ?

lto efforts have been made for Cachy and it was painful

• Major issues:
  thin lto brakes corefreq #458
  Failure to build dkms modules #435
  DKMS compilations fails on 6.3 #422
  kernel 5.14 build fails #272

If you are ok to PR a new Makefile, please make sure to test all other distros

[bubbleguuum]

Thank you for your reply.

Hello,

in the Makefile, install invocations could use its -D option to create the target directory path if necessary. When installing in a sandbox compile environment, $PREFIX/bin and $PREFIX/lib/systemd/system may not exist. This can trivially be fixed in whatever package script creating these directories before invoking make, but it would still be nice if the Makefile created these.

$PREFIX might point to an empty directory. In that case make install will not produce the expected result.
Passing -D to install is harmless and does not need testing. It was even used in an older Makefile.
Anyway, not a big deal as it can be trivially fixed before calling make install, by creating the required directories.

I will try but I was expecting a Systemd distribution to already be set up with such directories. For this, I have to make non regression tests among all distributions and down to kernel 3

I also wished CFLAGS was honored.

Indeed. ArchLinux is also claiming the same. Passing optimization level, but not -O0 in kernel module, is the issue.

Can you tell if any of them is problematic, especially link time optimization (-flto) ?

lto efforts have been made for Cachy and it was painful

* Major issues:
  [thin lto brakes corefreq #458](https://github.com/cyring/CoreFreq/issues/458)
  [Failure to build dkms modules #435](https://github.com/cyring/CoreFreq/issues/435)
  [DKMS compilations fails on 6.3 #422](https://github.com/cyring/CoreFreq/issues/422)
  [kernel 5.14 build fails #272](https://github.com/cyring/CoreFreq/issues/272)

If you are ok to PR a new Makefile, please make sure to test all other distros

What about adding a CUSTOM_CFLAGS variable passed to CC invocations ?

[cyring]

Passing -D to install is harmless and does not need testing. It was even used in an older Makefile.

True. But because of AlpineLinux or another musl issues, I met a case where install has no -D argument support
That was the reason of the change.

[bubbleguuum]

Ah OK, was not aware of that.

[cyring]

Passing -D to install is harmless and does not need testing. It was even used in an older Makefile.

What about adding a CUSTOM_CFLAGS variable passed to CC invocations ?

Do you have specs of this compiler variable ?

[bubbleguuum]

Passing -D to install is harmless and does not need testing. It was even used in an older Makefile.

What about adding a CUSTOM_CFLAGS variable passed to CC invocations ?

Do you have specs of this compiler variable ?

It's not a compiler variable. Just a variable that I named CUSTOM_CFLAGS but that could be anything else so you could do:

make CUSTOM_CFLAGS="..."

assuming a Makefile with:

$(CC) $(CUSTOM_CFLAGS) $(OPTIM_FLG) $(WARNING) $(DEFINITIONS) $(LAYOUT)

[cyring]

I see but it's the same purpose as the variable named WARNING

CFLAGS would be the best solution and -O has to be parsed with the fewest external commands as possible.
Once -O extracted to OPTIM_LVL, the remainder of CFLAGS will be passed to compiler.

[bubbleguuum]

OK, I did not realize WARNING could be used.

However, it might be best to leave CFLAGS alone and just use the defaults after all.
I got CoreFreq git packaged for openSUSE (including aarch64 which is new) on my private OBS repo here:
https://build.opensuse.org/package/show/home:bobbie424242/CoreFreq-git

Once 1.97.0 is officially released, I will update the distro official package.

[cyring]

Oh this is great what you are doing. I can now see an Arm64 build for another distro than my embedded Debian

Mine is a RK3588 processor, do you have some board's to test with ?

[bubbleguuum]

Unfortunately, I do not have Arm64 hardware to test it. But at least it builds fine on OBS Arm64 hardware.