linux-kernel - Re: Printing HW configuration on boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wg8O_CxYv3grek90cENnzGff1GYL+GGkweVX2t0Lr3KJg@mail.gmail.com>
Date:   Sat, 14 Oct 2023 15:32:06 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Artem S. Tashkinov" <aros@....com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Printing HW configuration on boot

On Sat, 14 Oct 2023 at 12:57, Artem S. Tashkinov <aros@....com> wrote:
>
> dmesg is an invaluable source of information about the system however
> oftentimes it's the only source of information and it gets really hard
> to extract information from it.

Honestly, I don't think this is "fixable". One issue is that different
people will want different "hardware info". Things like CPU model can
be interesting for some uses, but completely useless most of the time
for others. Same goes very much for GPU etc.

So then in other cases you want all of lspci etc, which is generally
too verbose for dmesg anyway (and even if it isn't, you again end up
with some people wanting not just vendor/model, but submodels and PCI
BAR information).

And if some problem happens during boot, you want the printouts to be
as immediate as possible, *not* some "summary once we've gathered
everything".

In other words: what you want for one bugreport is likely very
different what some other person wants for another unrelated issue,
both in content, verbosity, _and_ in timing.

For some issues, you'll want the dmidecode output, because motherboard
and BIOS versions matter. For other situations, none of it matters at
all, because saying "RPi 4 with 8MB" pretty much describes the
hardware. And other situations want a full acpidump.

You can always find *some* issue where exactly what you asked for is
relevant. But then 99% of the time it doesn't matter at all.

There simply isn't some kind of "one right output".

          Linus