GNU bug report logs - #39762
[PATCH] gnu: cpuid: Update to 20200211.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39762 in the body.
You can then email your comments to 39762 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Legoll <vincent.legoll <at> gmail.com>
To: guix-patches <at> gnu.org, cpuid <at> etallen.com
Subject: [PATCH] gnu: cpuid: Update to 20200211.
Date: Sun, 23 Feb 2020 23:54:38 +0100

[Message part 1 (text/plain, inline)]

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 <at> 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

[0001-gnu-cpuid-Update-to-20200211.patch (text/x-patch, attachment)]

Message #10 received at 39762-done <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: 39762-done <at> debbugs.gnu.org,
Cc: cpuid <at> etallen.com
Subject: Re: [bug#39762] [PATCH] gnu: cpuid: Update to 20200211.
Date: Mon, 24 Feb 2020 00:49:52 +0100

[Message part 1 (text/plain, inline)]

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 <at> 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 <at> 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

[signature.asc (application/pgp-signature, inline)]

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Todd Allen <todd <at> etallen.com>
To: Vincent Legoll <vincent.legoll <at> gmail.com>
Cc: guix-patches <at> gnu.org
Subject: Re: [PATCH] gnu: cpuid: Update to 20200211.
Date: Mon, 24 Feb 2020 08:12:48 -0700

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 <at> 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 <at> 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
> 

Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vincent Legoll <vincent.legoll <at> gmail.com>
To: Todd Allen <todd <at> etallen.com>
Cc: guix-patches <at> gnu.org
Subject: Re: [PATCH] gnu: cpuid: Update to 20200211.
Date: Mon, 24 Feb 2020 20:14:23 +0100

Hello Todd

thanks to chime in.

On Mon, Feb 24, 2020 at 4:12 PM Todd Allen <todd <at> 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...

-- 
Vincent Legoll

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.