[PATCH] gnu: cpuid: Update to 20200211.

  • Done
  • quality assurance status badge
Details
3 participants
  • Tobias Geerinckx-Rice
  • Todd Allen
  • Vincent Legoll
Owner
unassigned
Submitted by
Vincent Legoll
Severity
normal

Debbugs page

Vincent Legoll wrote 5 years ago
CAEwRq=qNXOz0Fs=D=PhfBCeyzrzO2Np3ccibYnir8yRcOCdazA@mail.gmail.com
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(-)

Toggle diff (23 lines)
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
Tobias Geerinckx-Rice wrote 5 years ago
(address . 39762-done@debbugs.gnu.org)(address . cpuid@etallen.com)
877e0cuan3.fsf@nckx
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 写道：
Toggle quote (4 lines)
> 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.

Toggle quote (5 lines)
> 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…

Toggle quote (2 lines)
> 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.

Toggle quote (4 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl5TD6EACgkQ2Imw8BjF
STw7qxAAgZFgGtg+tWsyuTJPtup0pYaFRMNMtS8lwN61gNBWIk5EEr62mFnJdrmp
3qN/5ObPVd6YpFW7IKBPurSVdQt8tDgbU3Bxdy3gDypbdeWzgid8pHtq3GKg6ai2
3vRV38GenzL3DoHMeJPzabMmHdnCve2pcj9h02iEdYm73ae58tm1TSyvVALd+IWU
OPzYBfJMWOIbk5foWkzUM+QKZSccPIyeJWVajEtZAEsgu8rGyitiebGdL+e96tui
pBPtHGq1bHyArVogv2qofRj70wg+TFak7jz+99SwpFXGvkCfflpTKpqMnN2SU25F
GsyLrXtEcq3Tc92sPTAwNPd/UPMw0m8neFhHTbA4lv+X66dbFmsnwkQ7Xn8OZ6Ml
C26xIGdbNhXzc2yyFJnQqwJs2TM2WexxKAPMeXfyWokhC5HaJjraoCjoIFMKaFUB
nX+68jkQz/CyCUfbGREuz+RwtxDnbkby3dx47DrVxychW/P0kviXoFlpRxDp5xvB
iLt8xY/uYmf68S0qkv775dhq/PY+ge/1Aj03+GnOkmK8QgMwVxdkI7GHRZZYfoW3
HRDWj2A6WDvnmymi7OoUTmDWWpJ0G15yk9NdClf32R2v23Q4VLFcuOnJLuUOuZFL
c/SeZQe+nTkHfuZDDTedWc2RDdHutIQ9I7z7MTVS0tj+8KX07R4=
=Xjrr
-----END PGP SIGNATURE-----

Closed
Todd Allen wrote 5 years ago
Re: [PATCH] gnu: cpuid: Update to 20200211.
(name . Vincent Legoll)(address . vincent.legoll@gmail.com)(address . guix-patches@gnu.org)
20200224151248.GA27726@toad
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:
Toggle quote (62 lines)
> 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 wrote 5 years ago
(name . Todd Allen)(address . todd@etallen.com)(address . guix-patches@gnu.org)
CAEwRq=oJy7g+Bb9W9HvkgCanbxNhBq35rcwBAHVVoagrv3QJoA@mail.gmail.com
Hello Todd

thanks to chime in.

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

Toggle quote (6 lines)
> 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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 39762@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 39762
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help