cyring / CoreFreq

CoreFreq : CPU monitoring and tuning software designed for 64-bit processors.
https://www.cyring.fr
GNU General Public License v2.0
1.97k stars 126 forks source link

DKMS with 5.12.0 #231

Closed inglor closed 3 years ago

inglor commented 3 years ago

Hi @cyring

Version 1.84 doesn't build with latest released kernel version 5.12. The develop branch works OK - time to release or patch the 1.84 release?

cyring commented 3 years ago

I have not jump to 5.12 yet. Developpements are too draft for a merge. I will push a 5.12 untested hotfix on master ASAP

cyring commented 3 years ago

I don't catch. I made a cherry-pick from the development commit which is fixing 5.12 But that fix was already in CoreFreq 1.84 ! https://github.com/cyring/CoreFreq/blob/61cabad55486b4b54c19080f76ed3e234df71afc/corefreqk.c#L52

Is your fork outdated ?

inglor commented 3 years ago

This is on Archlinux where the 5.12 is already in testing and some packages are already updated to 5.12 (like linux-ck)

The source is fetched from: https://github.com/cyring/CoreFreq/archive/tag/1.84.tar.gz

See my logs

$ sudo dkms install --no-depmod -m corefreq -v 1.84 -k 5.12.0-1-ck

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j32 KERNELRELEASE=5.12.0-1-ck -C /usr/src/corefreq-1.84 KERNELDIR=/usr/lib/modules/5.12.0-1-ck/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.12.0-1-ck (x86_64)
Consult /var/lib/dkms/corefreq/1.84/build/make.log for more information.
$ cat /var/lib/dkms/corefreq/1.84/build/make.log
DKMS make.log for corefreq-1.84 for kernel 5.12.0-1-ck (x86_64)
Fri 30 Apr 14:51:29 BST 2021
make: Entering directory '/usr/src/corefreq-1.84'
cc  -Wall corefreqd.c corefreqm.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=5250000000 -D UBENCH=0 \
  -o corefreqd -lpthread -lm -lrt
cc  -Wall \
  corefreq-cli.c corefreq-ui.c corefreq-cli-rsc.c \
  corefreq-cli-json.c corefreq-cli-extra.c \
  -D CORE_COUNT=256 -D TASK_ORDER=5 -D MAX_FREQ_HZ=5250000000 -D UBENCH=0  \
  -o corefreq-cli -lm -lrt
make -j1 -C /usr/lib/modules/5.12.0-1-ck/build M=/var/lib/dkms/corefreq/1.84/build modules
make[1]: Entering directory '/usr/src/corefreq-1.84'
make[1]: warning: -j1 forced in submake: resetting jobserver mode.
  CC [M]  /var/lib/dkms/corefreq/1.84/build/corefreqk.o
/var/lib/dkms/corefreq/1.84/build/corefreqk.c:52:26: error: expected declaration specifiers or ‘...’ before string constant
   52 | MODULE_SUPPORTED_DEVICE ("Intel,AMD,HYGON");
      |                          ^~~~~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:271: /var/lib/dkms/corefreq/1.84/build/corefreqk.o] Error 1
make[1]: *** [Makefile:1855: /var/lib/dkms/corefreq/1.84/build] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.12.0-1-ck/build'
make: *** [Makefile:70: all] Error 2
make: Leaving directory '/usr/src/corefreq-1.84'

The problem is master has moved on from 1.84 tag significanty which includes the compatibility with kernel 5.12. See comparison: https://github.com/cyring/CoreFreq/compare/1.84...master

cyring commented 3 years ago

I don't make use of tags beside to inform about major.minor but don't track revision My previous PKGBUILD did not fetch from archive but directly from current GitHub master, including latest revisions.

inglor commented 3 years ago

It's much better to have a stable tag than master which keeps evolving.

cyring commented 3 years ago

It's much better to have a stable tag than master which keeps evolving.

I'm mainly reserving revision for hotfixes on master and API changes, but indeed don't do tags whenever a revision happens.

That's why I used PKGBUILD that way:

# Maintainer: CyrIng <labs[at]cyring[dot]fr>
_gitname=CoreFreq
pkgname=corefreq-git
realname=corefreq
pkgver=<M>.<m>
pkgrel=<r>
pkgdesc="CoreFreq, Processor monitoring software with BIOS like functionalities"
arch=('x86_64')
url='https://github.com/cyring/CoreFreq'
license=('GPL2')
depends=('dkms')
makedepends=('git')
source=(git+${url}.git)
md5sums=('SKIP')
install=${realname}.install

package() {
        cd ${srcdir}/${_gitname}
        BINDIR=${pkgdir}/bin
        SRCTREE=${pkgdir}/usr/src
        DRVTREE=${SRCTREE}/corefreqk-${pkgver}
        # dkms setup
        install -Dm 0644 Makefile ${DRVTREE}/Makefile
        install -Dm 0644 dkms.conf ${DRVTREE}/dkms.conf
        install -Dm 0755 scripter.sh ${DRVTREE}/scripter.sh
        install -m 0644 *.c *.h ${DRVTREE}/
        # systemd setup
        install -Dm 0644 corefreqd.service \
                ${pkgdir}/usr/lib/systemd/system/corefreqd.service
}

where: pkgver for CoreFreq Major.minor pkgrel for CoreFreq revision

Indeed, this was not the ArchLinux way to do it but it was a mean to follow the project progress and I could notify the AUR of any new upstream revision.

inglor commented 3 years ago

I see. To summarize there's no tagged release which is compatible with 5.12. I'm not a fan of switching the corefreq stable package to tracking master, instead I will look at back-porting the patch~es~. edit: Just need the f6a350b

inglor commented 3 years ago

For future reference, downstream maintainers expect tags and will always follow such practices. It was also clear on my PR for adding the links for Archlinux packages.

cyring commented 3 years ago

For future reference, downstream maintainers expect tags and will always follow such practices. It was also clear on my PR for adding the links for Archlinux packages.

Thanks for your packages. Recreating the 1.84 tag. Hope it makes things better.