[RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Maciej W. Rozycki]

Hi,

 Resending as this has gone into void.  Original patches still apply in 
their original form at the same respective lines.

 I've noticed one of my systems shows this output in the kernel log:

Legacy DMI 2.0 present.
DMI:  /i430HX, BIOS 4.51 PG 05/13/98

which leaves something to desire.  While the contents of /sys/firmware/dmi 
remain the main source of DMI data, along with output from `dmidecode', 
the summary from the kernel log is often readily available with various 
reports, making it a point of easy reference.  Therefore I think empty 
names are best avoided if possible.

 The system in question is a Tyan Tomcat IV S1564D mainboard, which has 
its System Information all empty, not unreasonably as it was sold as a 
bare board for field integration rather that a complete system.  It does 
have the manufacturer correctly recorded with Base Board Information 
though.

 I have therefore made this mini patch series, with 2/2 printing the board 
manufacturer if none has been given for the system, and including 1/2 as 
well to prevent a trailing slash with an empty board name, following my 
observation made with an unrelated issue where the reporter included a log 
with just "/" shown as the system name.

 See individual change descriptions for further details.

 Please apply.

  Maciej

[RESEND][PATCH 1/2] firmware: dmi: Prevent empty board name from being logged

[Maciej W. Rozycki]

Some systems do provide DMI entries for Base Board Information, however 
the strings supplied are null, e.g:

Legacy DMI 2.0 present.
DMI: /, BIOS 4.51 PG 09/11/97

Do not log the slash along with the empty board name in that case as it 
carries no real information.  If it's important to tell an inexistent 
and an empty board name apart, then all DMI information can be retrieved 
from sysfs and/or with `dmidecode'.

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
 drivers/firmware/dmi_scan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-macro-ide-tty/drivers/firmware/dmi_scan.c
===================================================================
--- linux-macro-ide-tty.orig/drivers/firmware/dmi_scan.c
+++ linux-macro-ide-tty/drivers/firmware/dmi_scan.c
@@ -544,7 +544,7 @@ static void __init dmi_format_ids(char *
 			    dmi_get_system_info(DMI_PRODUCT_NAME));
 
 	board = dmi_get_system_info(DMI_BOARD_NAME);
-	if (board) {
+	if (board && *board) {
 		c += scnprintf(buf + c, len - c, "/");
 		c += print_filtered(buf + c, len - c, board);
 	}

[RESEND][PATCH 2/2] firmware: dmi: Log board vendor if no system vendor has been given

[Maciej W. Rozycki]

Some systems do not provide any names with System Information, e.g. the 
Tyan Tomcat IV S1564D mainboard reports:

Legacy DMI 2.0 present.
DMI:  /i430HX, BIOS 4.51 PG 05/13/98

This is not unreasonable given that it was retailed as a bare mainboard 
rather that a complete system, so no information could have been known 
about the integrator.  It does have the manufacturer correctly recorded 
with Base Board Information though:

Handle 0x0001
	DMI type 1, 8 bytes.
	System Information
		Manufacturer:
		Product Name:
		Version:
		Serial Number:
Handle 0x0002
	DMI type 2, 8 bytes.
	Base Board Information
		Manufacturer: Tyan Computer Corp
		Product Name: i430HX
		Version:
		Serial Number:

Resort to logging the board manufacturer then if none has been given for 
the system.  Also refrain from including the separating slash if no name 
has been given for the system.

Output is now:

Legacy DMI 2.0 present.
DMI: Tyan Computer Corp i430HX, BIOS 4.51 PG 05/13/98

for said board, surely more informative (of course a better name could 
have been chosen for the product than just "i430HX", but there you go).

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
---
 drivers/firmware/dmi_scan.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

linux-dmi-board-vendor.diff
Index: linux-macro-ide-tty/drivers/firmware/dmi_scan.c
===================================================================
--- linux-macro-ide-tty.orig/drivers/firmware/dmi_scan.c
+++ linux-macro-ide-tty/drivers/firmware/dmi_scan.c
@@ -535,17 +535,23 @@ static int __init print_filtered(char *b
 static void __init dmi_format_ids(char *buf, size_t len)
 {
 	int c = 0;
+	const char *vendor;
 	const char *board;	/* Board Name is optional */
+	const char *name;
 
-	c += print_filtered(buf + c, len - c,
-			    dmi_get_system_info(DMI_SYS_VENDOR));
+	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
+	if (!vendor || !*vendor)
+		vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
+	c += print_filtered(buf + c, len - c, vendor);
 	c += scnprintf(buf + c, len - c, " ");
-	c += print_filtered(buf + c, len - c,
-			    dmi_get_system_info(DMI_PRODUCT_NAME));
+
+	name = dmi_get_system_info(DMI_PRODUCT_NAME);
+	c += print_filtered(buf + c, len - c, name);
 
 	board = dmi_get_system_info(DMI_BOARD_NAME);
 	if (board && *board) {
-		c += scnprintf(buf + c, len - c, "/");
+		if (name && *name)
+			c += scnprintf(buf + c, len - c, "/");
 		c += print_filtered(buf + c, len - c, board);
 	}
 	c += scnprintf(buf + c, len - c, ", BIOS ");

[PING][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Maciej W. Rozycki]

On Sun, 2 Jan 2022, Maciej W. Rozycki wrote:

>  Resending as this has gone into void.  Original patches still apply in 
> their original form at the same respective lines.

 Ping for:
<https://lore.kernel.org/lkml/alpine.DEB.2.21.2201020127140.56863@angie.orcam.me.uk/>.

 Series re-verified against 5.17-rc2.

  Maciej

[PING^2][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Maciej W. Rozycki]

On Sun, 2 Jan 2022, Maciej W. Rozycki wrote:

>  Resending as this has gone into void.  Original patches still apply in 
> their original form at the same respective lines.

 Ping for:
<https://lore.kernel.org/lkml/alpine.DEB.2.21.2201020127140.56863@angie.orca
m.me.uk/>.

  Maciej

[PING^3][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Maciej W. Rozycki]

On Sun, 2 Jan 2022, Maciej W. Rozycki wrote:

>  Resending as this has gone into void.  Original patches still apply in 
> their original form at the same respective lines.

 Ping for:
<https://lore.kernel.org/lkml/alpine.DEB.2.21.2201020127140.56863@angie.orcam.me.uk/>.

  Maciej

[PING^4][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Maciej W. Rozycki]

On Sun, 2 Jan 2022, Maciej W. Rozycki wrote:

>  Resending as this has gone into void.  Original patches still apply in 
> their original form at the same respective lines.

 Ping for:
<https://lore.kernel.org/lkml/alpine.DEB.2.21.2201020127140.56863@angie.orcam.me.uk/>.

  Maciej

[PING^5][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Maciej W. Rozycki]

On Sun, 2 Jan 2022, Maciej W. Rozycki wrote:

>  Resending as this has gone into void.  Original patches still apply in 
> their original form at the same respective lines.

 Ping for:
<https://lore.kernel.org/lkml/alpine.DEB.2.21.2201020127140.56863@angie.orcam.me.uk/>.

  Maciej

[PING^6][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Maciej W. Rozycki]

On Sun, 2 Jan 2022, Maciej W. Rozycki wrote:

>  Resending as this has gone into void.  Original patches still apply in 
> their original form at the same respective lines.

 Ping for:
<https://lore.kernel.org/lkml/alpine.DEB.2.21.2201020127140.56863@angie.orcam.me.uk/>.

  Maciej

Re: [PING^6][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Jean Delvare]

Hi Maciej,

>  I don't know if Jean means to continue maintaining the DMI subsystem, but 
> either way it looks to me like a stalemate.  I don't feel like it's a set 
> of changes that requires a lot of consideration, the situation is IMO 
> quite straightforward here and the result a clear improvement.

If you genuinely think that kernel patches should be applied without
being reviewed because they are "quite straightforward and the result
is a clear improvement" then I advise you refrain from touching kernel
code at all.

Jean is busy doing things that matter in other areas, things which
surprisingly are always more important than adding code to the kernel
to essentially slightly improve the format of an informative line in
the boot log of a 20-year old systems with crappy DMI data.

If you think this is the best use of your own time then you can keep
pinging me every other week for another year, but that's not going to
change my priorities. I'll eventually get to your patches when I have
less on my plate, regardless.

>  Can you therefore please advise who can review this patch series (I can 
> re-repost if needed) or otherwise how to proceed with this submission?

And no, bothering Linus to solve that kind of situation is NOT how
things work. Your patches have been posted publicly several times,
pinged way too many times already, yet nobody has shown any interest in
them. Maybe this means something.

-- 
Jean Delvare
SUSE L3 Support

Re: [PING^6][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log

[Maciej W. Rozycki]

Jean,

> >  I don't know if Jean means to continue maintaining the DMI subsystem, but 
> > either way it looks to me like a stalemate.  I don't feel like it's a set 
> > of changes that requires a lot of consideration, the situation is IMO 
> > quite straightforward here and the result a clear improvement.
> 
> If you genuinely think that kernel patches should be applied without
> being reviewed because they are "quite straightforward and the result
> is a clear improvement" then I advise you refrain from touching kernel
> code at all.

 Well, I have worked with Linux (and other free software projects) both as 
a code contributor and a reviewer/maintainer for some 25 years now and I 
know very well what the responsibilities are for both sides.

 And surely I have not asked for this particular patch set to be accepted 
without a review, but for assistance with the review.  I do hope I have 
made it clear enough in my message.

> Jean is busy doing things that matter in other areas, things which
> surprisingly are always more important than adding code to the kernel
> to essentially slightly improve the format of an informative line in
> the boot log of a 20-year old systems with crappy DMI data.

 The incentive for my proposal was the lack of good identification given 
it the kernel log: <https://pastebin.com/QXaUsCV4>, which is generally the 
only source that can be reliably referred via Internet searches; people do 
not publish their sysfs data.

 Said log was posted in the course of investigating an IRQ routing bug: 
<https://lore.kernel.org/r/60B24AC2.9050505@gmail.com>, 
<https://lore.kernel.org/r/60E726E2.2050104@gmail.com/>, and ultimately I 
have sorted the problem in a generic way that does not require a DMI quirk 
to be added; cf.:
<https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=ac7cd5e16df8696c39e29b03dfedf069a025b822>, 
<https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=5a0e5fa957db79177baa851d687b6f6aa5a0be96>, 
<https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=fe62bc23620fa027162e05594a610ff5e556496a>.

 However that does not mean we should continue logging crappy data.  This 
is because evidently people still want to use these systems, and next time 
we may not be so lucky as to avoid relying on DMI data, however limited.

> If you think this is the best use of your own time then you can keep
> pinging me every other week for another year, but that's not going to
> change my priorities. I'll eventually get to your patches when I have
> less on my plate, regardless.

 We all are busy, aren't we?  If you cannot perform your maintainer's 
duties for a given subsystem in a timely manner, not even to send a note 
that the waiting queue is long, then perhaps you should reconsider if you 
can afford the post?

 NB I have fixed Nikolai's problem even though I am not a maintainer for 
the relevant subsystem, so I have no obligation of any kind there, unlike 
actual maintainers.

> >  Can you therefore please advise who can review this patch series (I can 
> > re-repost if needed) or otherwise how to proceed with this submission?
> 
> And no, bothering Linus to solve that kind of situation is NOT how
> things work. Your patches have been posted publicly several times,
> pinged way too many times already, yet nobody has shown any interest in
> them. Maybe this means something.

 Whatever your priorities are it does mean exactly what I have implied in 
my message: that evidence shows the maintenance of the DMI subsystem does 
not work.

 Therefore I have referred to the chief maintainer of the project, the 
only sensible action given the state of affairs.  This is because as you 
have correctly observed this patch set has been already pinged too many 
times and (as a general life rule) you can't expect a different outcome 
from the same action repeated, so if things repeatedly do not work, then 
you need to try something else.

 Please refer to this paragraph:

"Once upon a time, patches used to disappear into the void without comment,
but the development process works more smoothly than that now.  You should
receive comments within a week or so; if that does not happen, make sure
that you have sent your patches to the right place.  Wait for a minimum of
one week before resubmitting or pinging reviewers - possibly longer during
busy times like merge windows."

in Documentation/process/submitting-patches.rst too, which I think gives a 
good overview of the practices and timelines expected from submitters and 
maintainers.  I have to admit that I waited a bit longer than a week 
before I started pinging though.

 In most free software projects the general/head maintainter(s) step in by 
themselves with overdue reviews if subsystem-specific ones are too busy to 
handle submissions in a timely manner, however I do realise Linux has 
grown too large for this approach to be feasible.

 Thank you for your time spent to write your reply.

 NB it is generally accepted that publishing messages sent privately is 
inappropriate without obtaining consent first from the involved parties.  
Please assume my previous consent for your posting on this occasion 
though.

  Maciej