[bug#39762] gnu: cpuid: Update to 20200211.
diff mbox series

Message ID CAEwRq=qNXOz0Fs=D=PhfBCeyzrzO2Np3ccibYnir8yRcOCdazA@mail.gmail.com
State Accepted
Headers show
Series
  • [bug#39762] gnu: cpuid: Update to 20200211.
Related show

Checks

Context Check Description
cbaines/comparison success View comparision
cbaines/git branch success View Git branch
cbaines/applying patch fail View Laminar job

Commit Message

Vincent Legoll Feb. 23, 2020, 10:54 p.m. UTC
Looks like it is still working in a guix VM running on AMD ryzen 3700X host.

But there is some output differences between previous version and this one.

in raw mode (cpuid -r), it outputs one more line per core:

0x20000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000

which is probably OK, looks like the change:
Sun Feb  2 2020 Todd Allen <todd.allen@etallen.com>
        * cpuid.c: Added leaf walking of the 0x20000000 (Intel Phi) range
        [...]

But in normal mode, output changed a lot, some separators changed from ":"
to "=", a lot of reported values, new things... This will probably break
any simplistic parsing of that output, if there is anything doing that in
guix...

Having a cursory look at the changelog, it looks like this is getting a lot
more change since the beginning of this year, or something else.

Maybe Tood Allen can give us a hint...

Guixers, please advise how to proceed further.

Thanks--
Vincent Legoll

Comments

Tobias Geerinckx-Rice via Guix-patches via Feb. 23, 2020, 11:49 p.m. UTC | #1
Vincent,

Thanks for the update!  I only recently (this year?) learnt of 
this readable alternative to /proc/cpuinfo.  Glad to hear it's 
seeing more action.

Vincent Legoll 写道:
> But in normal mode, output changed a lot, some separators 
> changed from ":"
> to "="

This was deliberate, for consistency:

  Wed Feb  5 2020 Todd Allen <todd.allen@etallen.com>
    * cpuid.c: Changed mp_synth fields to use '=' separator 
    instead of ':',
      like every other value.
    * cpuid.c: Changed processor serial number to use '=' 
    separator instead
      of ':', like every other value.

> a lot of reported values, new things... This will probably break
> any simplistic parsing of that output, if there is anything 
> doing that in
> guix...

No:

  ~ λ guix refresh -l cpuid
  No dependents other than itself: cpuid@20200116

It's possible there's something out there calling cpuid from 
$PATH, but…

> Guixers, please advise how to proceed further.

…honestly, you're overthinking it. :-)  There's a time to be 
cautious but bumping cpuid is probably not it.

Guix is exceptionally good at installing previous versions of 
packages for those who disagree.  I've pushed your patch as 
08fee94d0fd96ea2b40f9fec80dc3fa19e283019.

> Subject: [PATCH] gnu: cpuid: Update to 20200211. * 
> gnu/packages/linux.scm
> (cpuid): Update to 20200211.

Note that git expects an empty line (newline) between the commit 
summary and the body of the message:

  gnu: cpuid: Update to 20200211.

  * gnu/packages/linux.scm (cpuid): Update to 20200211.

Thanks again,

T G-R
Todd Allen Feb. 24, 2020, 3:12 p.m. UTC | #2
Vincent,

Yes, often cpuid changes because of new features in the CPUID instruction, or
because of new CPUs determinable by the (synth) and (uarch synth) "leaves".
Sometimes it's because there was a feature I didn't know existed, like 0x2000000
leaves for Itanium.  The ":" change to "=" in a couple cases was deliberate.  It
had been inconsistent before.

Todd

On Sun, Feb 23, 2020 at 11:54:38PM +0100, Vincent Legoll wrote:
> Looks like it is still working in a guix VM running on AMD ryzen 3700X host.
> 
> But there is some output differences between previous version and this one.
> 
> in raw mode (cpuid -r), it outputs one more line per core:
> 
> 0x20000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
> 
> which is probably OK, looks like the change:
> Sun Feb  2 2020 Todd Allen <todd.allen@etallen.com>
>         * cpuid.c: Added leaf walking of the 0x20000000 (Intel Phi) range
>         [...]
> 
> But in normal mode, output changed a lot, some separators changed from ":"
> to "=", a lot of reported values, new things... This will probably break
> any simplistic parsing of that output, if there is anything doing that in
> guix...
> 
> Having a cursory look at the changelog, it looks like this is getting a lot
> more change since the beginning of this year, or something else.
> 
> Maybe Tood Allen can give us a hint...
> 
> Guixers, please advise how to proceed further.
> 
> Thanks--
> Vincent Legoll

> From f15fe227325fe1744ecf58d6bfe513e6c97026fe Mon Sep 17 00:00:00 2001
> From: Vincent Legoll <vincent.legoll@gmail.com>
> Date: Sun, 23 Feb 2020 23:15:33 +0100
> Subject: [PATCH] gnu: cpuid: Update to 20200211. * gnu/packages/linux.scm
>  (cpuid): Update to 20200211.
> 
> ---
>  gnu/packages/linux.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
> index f0fd2fb5df..3fdc716545 100644
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -5626,14 +5626,14 @@ available in the kernel Linux.")
>  (define-public cpuid
>    (package
>      (name "cpuid")
> -    (version "20200116")
> +    (version "20200211")
>      (source (origin
>                (method url-fetch)
>                (uri (string-append "http://www.etallen.com/cpuid/cpuid-"
>                                    version ".src.tar.gz"))
>                (sha256
>                 (base32
> -                "1gxi4iwy6j366l6bkj1yyxhrk1rxmwfp498gikfxn8xwhij9dn0a"))))
> +                "06sjbqqp80l7nhsp6khglkzdp9qy4vhbvjxbfilznhsmrqiwlw55"))))
>      (build-system gnu-build-system)
>      (arguments
>       '(#:make-flags '("CC=gcc")
> -- 
> 2.25.1
>
Vincent Legoll Feb. 24, 2020, 7:14 p.m. UTC | #3
Hello Todd

thanks to chime in.

On Mon, Feb 24, 2020 at 4:12 PM Todd Allen <todd@etallen.com> wrote:

> Yes, often cpuid changes because of new features in the CPUID instruction, or
> because of new CPUs determinable by the (synth) and (uarch synth) "leaves".
> Sometimes it's because there was a feature I didn't know existed, like 0x2000000
> leaves for Itanium.  The ":" change to "=" in a couple cases was deliberate.  It
> had been inconsistent before.

Thanks also for the details, I was just not expecting that much
changes initially when
doing a refresh only a few weeks after the preceding one. That means you're doig
lots of work, which is great !

And to Tobias, yes, I was erring on the (too much) safe side, not
really being sure
what I'm doing... I'm still fairly new to guix, even if I lurked in
the vicinity for a long
time. Looks like I'm digging a bit deeper this time (bare-metal
install on an old laptop
in addition to the VM I did my previous attempts with...) And while
trying to be useful,
I don't want to disrupt or make others loose time on my early mistakes...

Thanks all for the help, I'll go package something else now...

Patch
diff mbox series

From f15fe227325fe1744ecf58d6bfe513e6c97026fe Mon Sep 17 00:00:00 2001
From: Vincent Legoll <vincent.legoll@gmail.com>
Date: Sun, 23 Feb 2020 23:15:33 +0100
Subject: [PATCH] gnu: cpuid: Update to 20200211. * gnu/packages/linux.scm
 (cpuid): Update to 20200211.

---
 gnu/packages/linux.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index f0fd2fb5df..3fdc716545 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -5626,14 +5626,14 @@  available in the kernel Linux.")
 (define-public cpuid
   (package
     (name "cpuid")
-    (version "20200116")
+    (version "20200211")
     (source (origin
               (method url-fetch)
               (uri (string-append "http://www.etallen.com/cpuid/cpuid-"
                                   version ".src.tar.gz"))
               (sha256
                (base32
-                "1gxi4iwy6j366l6bkj1yyxhrk1rxmwfp498gikfxn8xwhij9dn0a"))))
+                "06sjbqqp80l7nhsp6khglkzdp9qy4vhbvjxbfilznhsmrqiwlw55"))))
     (build-system gnu-build-system)
     (arguments
      '(#:make-flags '("CC=gcc")
-- 
2.25.1