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