[RFE] systemd-hostnamed: Add device/hardware model field

[felipeborges]

Is your feature request related to a problem? Please describe.
With more vendors shipping Linux desktops out of the box, we started to have a necessity of telling machines apart for better bug triaging. In GNOME Control Center we want to show a "Model" field with this information, so users can provide hardware information while reporting bugs. See https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/723

Describe the solution you'd like
I suggest we add a field in hostnamed to query this info from /sys/class/dm/id/... so GNOME and other DEs can consume this over DBus and show this info in the UI appropriately.

Describe alternatives you've considered
Reading this directly instead of relying on hostnamed. :)

[felipeborges]

Is this something that would be wanted/accepted? I am willing to propose a Pull Request.

[hadess]

I'm fairly confident that thise would be accepted, can you prepare a PR for this?
@jwrdegoede that might be of interest as well.

[zdzichu]

It would need some filtering for common wrong values. 2 out of 3 systems I've checked have To be filled by O.E.M. in product_family.

[hadess]

It would need some filtering for common wrong values. 2 out of 3 systems I've checked have To be filled by O.E.M. in product_family.

That's the whole point of having something in between system apps and the raw data exported by the firmware.

[felipeborges]

It would need some filtering for common wrong values. 2 out of 3 systems I've checked have To be filled by O.E.M. in product_family.

Yes, product_family was indeed a draft that worked for me.

The implementation should also account for empty/place holder values https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/soc-core.c#n1535

Hans advised me that product_family isn't present on most devices, that we should use product_name instead (except for Lenovo, which we should use product_version).

[felipeborges]

Does anybody have a suggestion for the human-readable name for this field? I have been thinking of "Device Model", but my low-level vocabulary is limited. :)

[hadess]

Model is probably close enough to Chassis to be understood.

[poettering]

So, adding this makes sense I guess. But let's do this properly, i.e. support that this information is supplied via hwdb, and then also fix #7390 at the same time.

i.e. hostnamed should read the modalias string from /sys/class/dmi/id/modalias and then pass it to sd_hwdb_get() (or sd_hwdb_seek()), and use appropriate fields from that source preferably over the stuff from the other attributes in /sys/class/dmi/id/*. This would then provide a very nice and simple way for people to supply us with data that overrides the typically low-quality stuff available through DMI.

[felipeborges]

Sounds like a good approach. Thank you!

I guess I should go about adding a new hwdb for this.

How would you prefer that I name this specific .hwdb file? Are there any docs regarding the priority prefix used in hwdb.d? Also, which properties (other than Model and Chassis) make sense to add to this db?

Sorry for the amount of questions, it is my first time playing with systemd's codebase.

[poettering]

Yes, the idea would be to ship a hwdb file for this that is initially relatively empty, but I am pretty sure we can populate it quickly with some basic entries, I hope @hadess, @jwrdegoede might have a few devices they'd be keen to contribute entries for.

Hmm, so in my mind I have been going forth and back how to best to the hwdb integration. I see too options:

1. the option I proposed above: hostnamed would read the DMI modalias string and then check the hwdb itself.

2. probably a better approach: we just let udev do its thing on the dmi device (it's a sysfs device after all), including the hwdb lookup. And then we just read the properties off that device.

I think I am now leading towards option 2. It has the benefit we can also use udev rules on the DMI device, which we can use to filter the bogus fields such as "To be filled by O.E.M.".

or in other words, let's make sure that udevadm info /sys/class/dmi/id shows us the cleaned up vendor/model/chassis data as regular properties, and the official API to get them would be using sd-device/libudev to read the props of that device, instead of sd-hwdb.

Note that udev implicitly appends all matching sd-hwdb to udev devices, hence to implement this there wouldn't even have to be any manual hwdb lookups added anywhere.

If we go this approach I figure we should follow our usually naming scheme for udev fields, i.e.

ID_VENDOR + ID_MODEL should be initialized directly from ATTR{sys_vendor} and ATTR{product_family} (or whatever works best on typical machines).

And then ID_VENDOR_FROM_DATABASE + ID_MODEL_FROM_DATABASE should be initialized from the hwdb entries for the DMI modalias string. hostnamed should then first look for the xyz_FROM_DATABASE props, and if they don#t exist use the ones without _FROM_DATABASE suffix.

These four fields are used for various kinds of devices already this way, hence re-using them on the DMI device appears very natural to me.

For the chassis we'd introduce a new prop ID_CHASSIS or so.

the two xyz_FROM_DATABASE props and ID_CHASSIS would come from the hwdb, the ID_VENDOR/ID_MODEL props would be determined via udev rules.

What I am wondering about: this will work on x86 machines, i.e. where DMI is a thing. I wonder how we can open this up on other systems, where DMI is not a thing. i.e. let's say a raspberry pi or so (which is devicetree iirc?). do they expose some identifying blob as a sysfs device somewhere, so that we can neatly run udev on it? Do they expose modalias strings? anyone knows? I figure hostnamed could check for a couple of different devices if need be, but it would be good to have at least some idea how this would look on other archs, even if we don't implement this initially.

[phomes]

Some info from a rpi4 B 1.1:

With fedora rawhide aarch64 there is a modalias:

$ cat /sys/class/dmi/id/modalias
dmi:bvnU-Boot:bvr2020.04:bd04/20/2020:svnraspberrypi:pnrpi:pvr:rvnraspberrypi:rnrpi:rvr:cvnraspberrypi:ct3:cvr:

On rasbian there is not. One way to get the model info for the rpi is from the end of /proc/cpui nfo.

Hardware : BCM2835
Revision : c03111
Serial : (I removed this)
Model : Raspberry Pi 4 Model B Rev 1.1

[gicmo]

Yes, the idea would be to ship a hwdb file for this that is initially relatively empty, but I am pretty sure we can populate it quickly with some basic entries, I hope @hadess, @jwrdegoede might have a few devices they'd be keen to contribute entries for.

I needed host identification for bolt (!233) the other day and @jwrdegoede sent me this github repo which contains a lot of info for various devices: https://github.com/linuxhw/DMI.git (Lenovo is the most obvious special case with product_name vs product_version).