10 ms·

Lscpu for OpenBSD/FreeBSD

41 points by nanxiao 9y ago

Crontab 9y ago
Very nice. Hopefully, a "lsblk" will follow, as that is one of my favorite Linux commands.
- ComSubVie 9y ago
  Didn't know it, thank you very much for the tip. That tool would have come handy quite a few times already.
  - Crontab 9y ago
    If you are like me and prefer to mount things manually, it is a real friend.
- HeadlessChild 9y ago
  That's a tool I abuse daily at work.
- cat199 9y ago
  am out of date on freebsd, but IIRC you can 'camcontrol devlist'.. openbsd not so much.
  - cat199 9y ago
    this doesn't give fs-on-disk info however
    - rjsw 9y ago
      You can use dumpfs for that.
    - vogon_laureate 9y ago
      you can use fstyp command https://www.freebsd.org/cgi/man.cgi?query=fstyp https://www.freebsd.org/cgi/man.cgi?query=fstyp
      - floatboth 9y ago
        doesn't recognize ZFS :D
        vogon_laureate 9y ago
        "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
  - Crontab 9y ago
    On OpenBSD, you can do something like: "sysctl hw.disknames"
debdrup 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
HeadlessChild 9y ago
Is this basically what `cat /proc/cpuinfo` is for Linux?
- mmarx 9y ago
  It is what `lscpu`is for Linux (which provides output quite similar, but not identical to `cat /proc/cpuinfo`).
loeg 9y ago
Related: x86info (which produces some similar information on x86) is cross-platform, and works on FreeBSD (and likely OpenBSD).
vogon_laureate 9y ago
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 9y ago
  What about platforms that don't support DMI?
  - vogon_laureate 9y ago
    _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
deleted 9y ago
[deleted]
vogon_laureate 9y ago
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
- vogon_laureate 9y ago
  Except it's better formatted than that. :-)
- ajross 9y ago
  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.
gigatexal 9y ago
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 9y ago
  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.
  - glandium 9y ago
    And Solaris has zones and I/O completion ports. So what?
    - X86BSD 9y ago
      Solaris is dead. Maybe you didn't get the memo? And your comment has absolutely nothing to do with Linux or the Linux community.
      - floatboth 9y ago
        Solaris™ is dead, but everyone calls illumos "Solaris" :D
  - floatboth 9y ago
    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.
    - 9y ago

41 points by nanxiao 9y ago

Crontab 9y ago

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

ComSubVie 9y ago
Didn't know it, thank you very much for the tip. That tool would have come handy quite a few times already.
- Crontab 9y ago
  If you are like me and prefer to mount things manually, it is a real friend.
HeadlessChild 9y ago
That's a tool I abuse daily at work.
cat199 9y ago
am out of date on freebsd, but IIRC you can 'camcontrol devlist'.. openbsd not so much.
- cat199 9y ago
  this doesn't give fs-on-disk info however
  - rjsw 9y ago
    You can use dumpfs for that.
  - vogon_laureate 9y ago
    you can use fstyp command https://www.freebsd.org/cgi/man.cgi?query=fstyp https://www.freebsd.org/cgi/man.cgi?query=fstyp
    - floatboth 9y ago
      doesn't recognize ZFS :D
      - vogon_laureate 9y ago
        "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
- Crontab 9y ago
  On OpenBSD, you can do something like: "sysctl hw.disknames"

debdrup 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.

HeadlessChild 9y ago

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

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

loeg 9y ago

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

vogon_laureate 9y ago

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 9y ago
What about platforms that don't support DMI?
- vogon_laureate 9y ago
  _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

deleted 9y ago

[deleted]

vogon_laureate 9y ago

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

vogon_laureate 9y ago
Except it's better formatted than that. :-)
ajross 9y ago
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.

gigatexal 9y ago

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 9y ago
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.
- glandium 9y ago
  And Solaris has zones and I/O completion ports. So what?
  - X86BSD 9y ago
    Solaris is dead. Maybe you didn't get the memo? And your comment has absolutely nothing to do with Linux or the Linux community.
    - floatboth 9y ago
      Solaris™ is dead, but everyone calls illumos "Solaris" :D
- floatboth 9y ago
  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.
  - 9y ago