Lscpu for OpenBSD/FreeBSD | Hacker News Reader

Lscpu for OpenBSD/FreeBSD

github.com

41 pointsnanxiao37 comments

Open articleView on HN

FreeBSD has 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

Except it's better formatted than that. :-)

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.

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.

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.

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.

  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.

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

  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.

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.

Hot-adding CPUs after boot? Not theoretical; I've done this on Linux VMs.

As far as I know, not supported under FreeBSD yet and definitely not on OpenBSD.

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

Didn't know it, thank you very much for the tip. That tool would have come handy quite a few times already.

If you are like me and prefer to mount things manually, it is a real friend.

That's a tool I abuse daily at work.

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

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

You can use dumpfs for that.

you can use fstyp command https://www.freebsd.org/cgi/man.cgi?query=fstyp

doesn't recognize ZFS :D

"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

On OpenBSD, you can do something like:

"sysctl hw.disknames"

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)?

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.

And Solaris has zones and I/O completion ports. So what?

Solaris is dead. Maybe you didn't get the memo?

And your comment has absolutely nothing to do with Linux or the Linux community.

Solaris™ is dead, but everyone calls illumos "Solaris" :D

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

More actual disasters though: signalfd (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.

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.

What is the BSD way to get this information ?

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

FreeBSD has the dmidecode command 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

What about platforms that don't support DMI?

_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

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

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

Reply on news.ycombinator.com