* [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log @ 2022-01-02 23:24 Maciej W. Rozycki 2022-01-02 23:24 ` [RESEND][PATCH 1/2] firmware: dmi: Prevent empty board name from being logged Maciej W. Rozycki ` (7 more replies) 0 siblings, 8 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-01-02 23:24 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RESEND][PATCH 1/2] firmware: dmi: Prevent empty board name from being logged 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki @ 2022-01-02 23:24 ` Maciej W. Rozycki 2022-01-02 23:24 ` [RESEND][PATCH 2/2] firmware: dmi: Log board vendor if no system vendor has been given Maciej W. Rozycki ` (6 subsequent siblings) 7 siblings, 0 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-01-02 23:24 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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); } ^ permalink raw reply [flat|nested] 11+ messages in thread
* [RESEND][PATCH 2/2] firmware: dmi: Log board vendor if no system vendor has been given 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki 2022-01-02 23:24 ` [RESEND][PATCH 1/2] firmware: dmi: Prevent empty board name from being logged Maciej W. Rozycki @ 2022-01-02 23:24 ` Maciej W. Rozycki 2022-02-01 10:49 ` [PING][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki ` (5 subsequent siblings) 7 siblings, 0 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-01-02 23:24 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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 "); ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PING][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki 2022-01-02 23:24 ` [RESEND][PATCH 1/2] firmware: dmi: Prevent empty board name from being logged Maciej W. Rozycki 2022-01-02 23:24 ` [RESEND][PATCH 2/2] firmware: dmi: Log board vendor if no system vendor has been given Maciej W. Rozycki @ 2022-02-01 10:49 ` Maciej W. Rozycki 2022-02-15 21:29 ` [PING^2][PATCH " Maciej W. Rozycki ` (4 subsequent siblings) 7 siblings, 0 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-02-01 10:49 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PING^2][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki ` (2 preceding siblings ...) 2022-02-01 10:49 ` [PING][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki @ 2022-02-15 21:29 ` Maciej W. Rozycki 2022-03-01 20:43 ` [PING^3][PATCH " Maciej W. Rozycki ` (3 subsequent siblings) 7 siblings, 0 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-02-15 21:29 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PING^3][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki ` (3 preceding siblings ...) 2022-02-15 21:29 ` [PING^2][PATCH " Maciej W. Rozycki @ 2022-03-01 20:43 ` Maciej W. Rozycki 2022-03-30 12:50 ` [PING^4][PATCH " Maciej W. Rozycki ` (2 subsequent siblings) 7 siblings, 0 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-03-01 20:43 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PING^4][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki ` (4 preceding siblings ...) 2022-03-01 20:43 ` [PING^3][PATCH " Maciej W. Rozycki @ 2022-03-30 12:50 ` Maciej W. Rozycki 2022-04-13 22:53 ` [PING^5][PATCH " Maciej W. Rozycki 2022-04-20 19:22 ` [PING^6][PATCH " Maciej W. Rozycki 7 siblings, 0 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-03-30 12:50 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PING^5][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki ` (5 preceding siblings ...) 2022-03-30 12:50 ` [PING^4][PATCH " Maciej W. Rozycki @ 2022-04-13 22:53 ` Maciej W. Rozycki 2022-04-20 19:22 ` [PING^6][PATCH " Maciej W. Rozycki 7 siblings, 0 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-04-13 22:53 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PING^6][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki ` (6 preceding siblings ...) 2022-04-13 22:53 ` [PING^5][PATCH " Maciej W. Rozycki @ 2022-04-20 19:22 ` Maciej W. Rozycki [not found] ` <alpine.DEB.2.21.2204271211090.9383@angie.orcam.me.uk> 7 siblings, 1 reply; 11+ messages in thread From: Maciej W. Rozycki @ 2022-04-20 19:22 UTC (permalink / raw) To: Jean Delvare; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <alpine.DEB.2.21.2204271211090.9383@angie.orcam.me.uk>]
* Re: [PING^6][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log [not found] ` <alpine.DEB.2.21.2204271211090.9383@angie.orcam.me.uk> @ 2022-04-27 15:19 ` Jean Delvare 2022-04-27 16:53 ` Maciej W. Rozycki 0 siblings, 1 reply; 11+ messages in thread From: Jean Delvare @ 2022-04-27 15:19 UTC (permalink / raw) To: torvalds, macro; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PING^6][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log 2022-04-27 15:19 ` Jean Delvare @ 2022-04-27 16:53 ` Maciej W. Rozycki 0 siblings, 0 replies; 11+ messages in thread From: Maciej W. Rozycki @ 2022-04-27 16:53 UTC (permalink / raw) To: Jean Delvare; +Cc: torvalds, linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-04-27 16:53 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-02 23:24 [RESEND][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki 2022-01-02 23:24 ` [RESEND][PATCH 1/2] firmware: dmi: Prevent empty board name from being logged Maciej W. Rozycki 2022-01-02 23:24 ` [RESEND][PATCH 2/2] firmware: dmi: Log board vendor if no system vendor has been given Maciej W. Rozycki 2022-02-01 10:49 ` [PING][PATCH 0/2] firmware: dmi: Avoid (some) empty names in kernel log Maciej W. Rozycki 2022-02-15 21:29 ` [PING^2][PATCH " Maciej W. Rozycki 2022-03-01 20:43 ` [PING^3][PATCH " Maciej W. Rozycki 2022-03-30 12:50 ` [PING^4][PATCH " Maciej W. Rozycki 2022-04-13 22:53 ` [PING^5][PATCH " Maciej W. Rozycki 2022-04-20 19:22 ` [PING^6][PATCH " Maciej W. Rozycki [not found] ` <alpine.DEB.2.21.2204271211090.9383@angie.orcam.me.uk> 2022-04-27 15:19 ` Jean Delvare 2022-04-27 16:53 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).