Skip to contentSkip to conversation

test11-pre5 breaks vmware

DISCUSSION Petr Vandrovec 6 participants 6 messages Nov 15, 2000 – Nov 16, 2000

lore
Share & tools
lore
#0 lore raw
Quoted 5 lines · Tigran Aivazian

You probably noticed this already but I just wanted to bring it to your attention that /usr/bin/vmware-config.pl script needs updating since the flags in /proc/cpuinfo is now called "features" so it otherwise fails complaining that my 2xP6 has no tsc. Trivial change but still worthy of propagating into your latest .tar.gz file for 2.4.x

Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK, I'll release patch for vmware, as I cannot stop kernel developers from changing field names :-)
Thanks for reporting,
Petr Vandrovec [email protected]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw
Quoted 11 lines · Petr Vandrovec
Quoted 5 lines · Tigran Aivazian

You probably noticed this already but I just wanted to bring it to your attention that /usr/bin/vmware-config.pl script needs updating since the flags in /proc/cpuinfo is now called "features" so it otherwise fails complaining that my 2xP6 has no tsc. Trivial change but still worthy of propagating into your latest .tar.gz file for 2.4.x

Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK, I'll release patch for vmware, as I cannot stop kernel developers from changing field names :-)

Actually, I know of at least one other shipping commercial product (Sitraka's JProbe Java Profiler) that will require patching because of this change. It seems unwise to be changing field names in commonly used /proc files like cpuinfo at this point in time.

Scott

Signature · 11 lines
=============================================================================
Scott Murray                                        email: [email protected]
http://www.interlog.com/~scottm                       ICQ: 10602428
-----------------------------------------------------------------------------
     "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#2 lore raw
In reply to Petr Vandrovec
Followup to:  <[email protected]>
By author:    Scott Murray <[email protected]>
In newsgroup: linux.dev.kernel
Quoted 10 lines
Quoted 4 lines

Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK, I'll release patch for vmware, as I cannot stop kernel developers from changing field names :-)

Actually, I know of at least one other shipping commercial product (Sitraka's JProbe Java Profiler) that will require patching because of this change. It seems unwise to be changing field names in commonly used /proc files like cpuinfo at this point in time.

The problem with "flags" is that it no longer contains quite the same information. Since the semantics of the field changed slightly, changing the field name is sometimes more correct.

Also, if a piece of software needs raw CPUID information (unlike the "cooked" one provided by recent kernels) it should use /dev/cpu/*/cpuid.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#3 lore raw
Quoted 9 lines
Quoted 5 lines

Actually, I know of at least one other shipping commercial product (Sitraka's JProbe Java Profiler) that will require patching because of this change. It seems unwise to be changing field names in commonly used /proc files like cpuinfo at this point in time.

The problem with "flags" is that it no longer contains quite the same information. Since the semantics of the field changed slightly, changing the field name is sometimes more correct.

The data sure looks like flags to me. If "flags" referred
to some specific Intel register, it could be just hex.
Anyway, breaking apps to make /proc pretty is just bad.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#4 lore raw
In reply to Petr Vandrovec
Quoted 3 lines · H. Peter Anvin

Also, if a piece of software needs raw CPUID information (unlike the "cooked" one provided by recent kernels) it should use /dev/cpu/*/cpuid.

Is it also OK to use the cpuid opcode in userspace ? (after checking for its presence with the 0x200000 eflags bit)

Signature · 6 lines
Michel "Walken" LESPINASSE
Of course I think I'm right. If I thought I was wrong, I'd change my mind.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#5 lore raw
In reply to Petr Vandrovec
Quoted 9 lines · Michel LESPINASSE
Quoted 3 lines · H. Peter Anvin

Also, if a piece of software needs raw CPUID information (unlike the "cooked" one provided by recent kernels) it should use /dev/cpu/*/cpuid.

Is it also OK to use the cpuid opcode in userspace ? (after checking for its presence with the 0x200000 eflags bit)

Only on single-CPU systems. What /dev/cpu/*/cpuid gives you is the ability to direct the CPUID request to a particular CPU.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/