
Lscpu for OpenBSD/FreeBSD - nanxiao
https://github.com/NanXiao/lscpu
======
vogon_laureate
FreeBSD has dmidecode
[https://www.freebsd.org/cgi/man.cgi?query=dmidecode](https://www.freebsd.org/cgi/man.cgi?query=dmidecode)

So you can do:

dmidecode -t processor -t cache

which produces the following output on my system:

# dmidecode 2.11 SMBIOS 2.6 present. Handle 0x0400, DMI type 4, 40 bytes

Processor Information Socket Designation: CPU1 Type: Central Processor Family:
Xeon Manufacturer: Intel ID: 52 06 02 00 FF FB EB BF Signature: Type 0, Family
6, Model 37, Stepping 2 Flags: FPU (Floating-point unit on-chip) VME (Virtual
mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time
stamp counter) MSR (Model specific registers) PAE (Physical address extension)
MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-
chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range
registers) PGE (Page global enable) MCA (Machine check architecture) CMOV
(Conditional move instruction supported) PAT (Page attribute table) PSE-36
(36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug
store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and
FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming
SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor
supported) PBE (Pending break enabled)

Version: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz Voltage: 1.2 V External Clock:
5860 MHz Max Speed: 3600 MHz Current Speed: 2933 MHz Status: Populated,
Enabled Upgrade: Socket LGA1366 L1 Cache Handle: 0x0700 L2 Cache Handle:
0x0701 L3 Cache Handle: 0x0702 Serial Number: Not Specified Asset Tag: Not
Specified Part Number: Not Specified Core Count: 2 Core Enabled: 2 Thread
Count: 4 Characteristics: 64-bit capable

~~~
ajross
DMI is a pure software table provided by the BIOS and maintained by the system
vendor. The linked tool looks like the output of CPUID reads, which are a
processor hardware interface.

Obviously they should match, but if they don't, DMI is going to be the one
lying.

------
debdrup
This is neat and all, but I'm not sure I understand how it's better than 'less
/var/run/dmesg.boot'? Which is not to say that this doesn't have any merit, I
just don't understand it.

~~~
alyandon
A trivial inspection of my FreeBSD 11.1 system's /var/run/dmesg.boot shows
that it doesn't contain all the information displayed by lscpu. So what's hard
to understand?

lscpu displays CPU information in a predictable, concise format whereas 'less
/var/run/dmesg.boot' requires you to read through a log file that contains a
subset of the same information that also happens to be interspersed among
unrelated log entries?

It'd probably be more fair to discuss the merits of lscpu vs some invocation
of grep '<some regex>' /var/run/dmesg.boot that produced similar output.

~~~
debdrup
As far as I can see (and comparing with the output on the github page), the
only thing missing from dmesg is the amount of cache and byte order within the
first 20 or so lines. One depends on CPU purchase, the other depends on the
ISA. Either way, they're not something I can do anything about even if I need
to know them - which, most of the time, I don't.

I'd argue that the reason you think lscpu is predictable and concise is that
you're used to reading it.

~~~
alyandon

      As far as I can see (and comparing with the output on the github page), the only 
      thing missing from dmesg is the amount of cache and byte order within the first 20 or so lines. 
    

Well, yes. A subset of the information and interspersed among unrelated log
entries as I stated.

    
    
      One depends on CPU purchase, the other depends on the ISA. Either way, they're not something 
      I can do anything about even if I need to know them - which, most of the time, I don't.
    

Great!

    
    
      I'd argue that the reason you think lscpu is predictable and concise is that you're used to reading it.
    

Actually, I've rarely used that command (probably a handful of times in the
past 5 years) so you're about as wrong as you can get when it comes to using
the familiarity argument. :)

I actually based my statement on:

    
    
      lscpu -> gives CPU information
      less dmesg.boot -> contains CPU information mixed in with other log entries
    

lscpu is more concise than the dmesg.boot log file

    
    
      lscpu -> fields have fixed fieldnames
      less dmesg.boot -> unstructured log entries
    

lscpu has predictable output compared to the dmesg.boot log file

In my world parsing output from command line tools that use predictable
identifiers in their output is easier than parsing similar data out of
unstructured logs.

~~~
GalacticDomin8r
> lscpu has predictable output compared to the dmesg.boot log file

The CPU info appears in the same place each time, assuming no other changes
took place. Even if something did it would effect only it's relative position.

And yes the extra info provided by lscpu is very irrelevant for nearly all use
cases.

> In my world parsing output from command line tools that use predictable
> identifiers in their output is easier than parsing similar data out of
> unstructured logs.

Sure, but if your argument is that you can't easily do this without the
reinvention of the wheel, I disagree.

~~~
alyandon

      The CPU info appears in the same place each time, assuming no other changes took place. 
      Even if something did it would effect only it's relative position.
    

The initial blob of CPU info, sure. I never really argued otherwise other than
to say the log file is unstructured data and the relevant CPU information is
not grouped together.

    
    
      # grep -n CPUs /var/run/dmesg.boot
      21:FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
    

I don't have a ton of other FreeBSD machines handy to check. Is the number of
cpus always line 21 of the dmesg.boot log? I mean sure, if it is there is some
consistency there but that information isn't grouped with the other.

    
    
      And yes the extra info provided by lscpu is very irrelevant for nearly all use cases.
    

Maybe for your use cases? Seems a little presumptuous to declare what
information is irrelevant for other people's use cases.

    
    
      Sure, but if your argument is that you can't easily do this without the reinvention of the wheel, I disagree.
    

That wasn't my argument at all.

~~~
floatboth
Not always line 21. Some stuff can appear before CPU info — like hypervisor
info and some weird errors:

    
    
        …
        SRAT: Ignoring memory at addr 0x80000200000
        VT(efifb): resolution 1024x768
        Hyper-V Version: 10.0.15063 [SP0]
          Features=0x2e7f<VPRUNTIME,TMREFCNT,SYNIC,SYNTM,APIC,HYPERCALL,VPINDEX,REFTSC,IDLE,TMFREQ>
          PM Features=0x0 [C2]
          Features3=0xed7b2<DEBUG,XMMHC,IDLE,NUMA,TMFREQ,SYNCMC,CRASH,NPIEP>
        Timecounter "Hyper-V" frequency 10000000 Hz quality 2000
        CPU: AMD Ryzen 7 1700 Eight-Core Processor           (3000.00-MHz K8-class CPU)
        Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
        …
    

but it's always in the first part of dmesg.

------
Crontab
Very nice. Hopefully, a "lsblk" will follow, as that is one of my favorite
Linux commands.

~~~
cat199
am out of date on freebsd, but IIRC you can 'camcontrol devlist'.. openbsd not
so much.

~~~
cat199
this doesn't give fs-on-disk info however

~~~
vogon_laureate
you can use fstyp command
[https://www.freebsd.org/cgi/man.cgi?query=fstyp](https://www.freebsd.org/cgi/man.cgi?query=fstyp)

~~~
floatboth
doesn't recognize ZFS :D

~~~
vogon_laureate
"When the -u flag is specified, fstyp also recognizes certain additional
metadata formats that cannot be handled using mount(8), such as geli(8)
providers, and ZFS pools."

[https://www.freebsd.org/cgi/man.cgi?query=fstyp](https://www.freebsd.org/cgi/man.cgi?query=fstyp)

------
gigatexal
This is cool don’t get me wrong but why Linux-ify the BSDs when you can just
adapt to the BSD way and use already existing tools (many of which are
mentioned in previous comments)?

~~~
X86BSD
What you ask is what many outside the Linux community are so annoyed and
frustrated with. The Linux communities complete inability to look outside
their echo chamber. Constantly reinventing the wheel poorly and in a broken
screw portability way. Instead of hacking together cgroups and namespaces they
should have simply ported the jail framework. Instead of epoll they should
have simply adopted kqueue. All they see is Linux only.

~~~
floatboth
To be fair, cgroups appeared before we got rctl/racct.

More actual disasters though: signalfd ([https://ldpreload.com/blog/signalfd-
is-useless](https://ldpreload.com/blog/signalfd-is-useless)), ALSA,
wireless_tools/iproute2(ip command)/iw (was it SO HARD to just keep improving
ifconfig?!), procfs/sysfs & udev.

~~~
X86BSD
If I logged on to a UNIX box, and ifconfig was not there I would install a
real UNIX. Seriously I am not going to hunt down or figure out why basic UNIX
tools, interfaces, or APIs are not there. I'm just going to write the OS off
as a busted trash fire and fix it using the above fix.

------
loeg
Related: x86info (which produces some similar information on x86) is cross-
platform, and works on FreeBSD (and likely OpenBSD).

------
vogon_laureate
FreeBSD has the dmidecode command
[https://www.freebsd.org/cgi/man.cgi?query=dmidecode](https://www.freebsd.org/cgi/man.cgi?query=dmidecode)

    
    
      eg. dmidecode -t processor -t cache
    

which on my system produces the following output:

    
    
      # dmidecode 2.11

SMBIOS 2.6 present.

Handle 0x0400, DMI type 4, 40 bytes Processor Information Socket Designation:
CPU1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: 52 06 02 00
FF FB EB BF Signature: Type 0, Family 6, Model 37, Stepping 2 Flags: FPU
(Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging
extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model
specific registers) PAE (Physical address extension) MCE (Machine check
exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware
supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page
global enable) MCA (Machine check architecture) CMOV (Conditional move
instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size
extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI
supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions
supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE
(Pending break enabled) Version: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
Voltage: 1.2 V External Clock: 5860 MHz Max Speed: 3600 MHz Current Speed:
2933 MHz Status: Populated, Enabled Upgrade: Socket LGA1366 L1 Cache Handle:
0x0700 L2 Cache Handle: 0x0701 L3 Cache Handle: 0x0702 Serial Number: Not
Specified Asset Tag: Not Specified Part Number: Not Specified Core Count: 2
Core Enabled: 2 Thread Count: 4 Characteristics: 64-bit capable

~~~
Skunkleton
What about platforms that don't support DMI?

~~~
vogon_laureate
_cpuid dumps detailed information about the CPU(s) gathered from the CPUID
instruction, and also determines the exact model of CPU(s) from that
information._

[https://www.freebsd.org/cgi/man.cgi?query=cpuid-
etallen](https://www.freebsd.org/cgi/man.cgi?query=cpuid-etallen)

------
HeadlessChild
Is this basically what `cat /proc/cpuinfo` is for Linux?

~~~
mmarx
It is what `lscpu`is for Linux (which provides output quite similar, but not
identical to `cat /proc/cpuinfo`).

