Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     linux-kernel@vger.kernel.org
From:   "Artem S. Tashkinov" <aros@gmx.com>
Subject: An initiative to collect unusual kernel messages and automatically
 create bugzilla.kernel.org bugs based on them
Message-ID: <aaece64f-8c6d-29c8-2aa1-34e6dd9378ac@gmx.com>
Date:   Wed, 5 May 2021 23:31:59 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hello!

Here's a proposal I've made in Redhat's bugzilla (it's been my distro
for more than two decades, so I think it's pertinent), PR1957520:

=2D-----------------------------------------------------------------

I've been thinking about this issue for a couple of years now and I
struggle to understand where and how it needs to be implemented.

We all know that the Linux kernel doesn't perfectly support all the
hardware around, and the second serious issue is that the Linux kernel
contains known workarounds for broken hardware but those are often not
properly organized and end users have no idea whether those workarounds
are mild and innocuous or they need to be taken care of.

I have a very unpopular idea to propose. Let's implement a strict opt-in
program and add it as an option in the Anaconda/Fedora/RHEL installer to
_anonymously_ collect unusual kernel messages and based on them
automatically create bugzilla.kernel.org bugs.

Why do I believe it's necessary?

If you run the following command on your Linux device right now you'll
see a ton of data which in a perfect world shouldn't be there, the
output of this command should be just empty but it's not:

dmesg -t --level=3Dalert,crit,err,warn

Of course some of the issues presented are known quirks which will never
be fixed, but users often have no way of knowing it and end up googling
each error message.

In a perfect world each of such messages should be followed by a good
explanation, e.g.

smpboot: 32 Processors exceeds NR_CPUS limit of 16 : this is a known bug
tracked as PR204813, it is safe to ignore it.

Or another message:

kernel: ACPI Warning: SystemIO range
0x0000000000000295-0x0000000000000296 conflicts with OpRegion
0x0000000000000290-0x0000000000000299 (\AMW0.SHWM)
(20201113/utaddress-204) : this is likely a problem with your EFI
firmware or a known bug: PR204807

In short, "bad" dmesg output should not be cryptic and Fedora may
actually start doing something about that.

Lastly, out of all active Linux users, I guess less than 0.1% actually
report bugs about their HW [support] and such an opt-in program could
actually resolve a ton of issues which are flying under the radar of
Linux developers.

Probably such a daemon for collecting anonymized kernel messages could
be implemented across all Linux distors right in the kernel itself but
that will require cooperation between Linux distros and the kernel which
I'm not sure will pan out.

I would love Fedora/Redhat/IBM to treat this proposal seriously and move
ahead with it regardless of what the Linux kernel community thinks about
it as it most likely will result in multiple bugs resolved or and kernel
messages made understandable for end users.

=2D-----------------------------------------------------------------

I would still be extremely glad and grateful if Linux kernel developers
chimed in and expressed their opinion about this program/initiative. I
believe it can have a great chance of resolving multiple not well known
issues in Linux hardware support and making `dmesg` messages a lot more
understandable and clear for Linux users without strong IT background.

Best regards,
Artem