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
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 <[email protected]>
---
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);
}
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 <[email protected]>
---
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 ");
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/[email protected]/>.
Series re-verified against 5.17-rc2.
Maciej
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/[email protected]
m.me.uk/>.
Maciej
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/[email protected]/>.
Maciej
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/[email protected]/>.
Maciej
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/[email protected]/>.
Maciej
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/[email protected]/>.
Maciej
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
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/[email protected]>,
<https://lore.kernel.org/r/[email protected]/>, 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