Re: [dmidecode] /sys/firmware interface?

[Leif Lindholm]

On Thu, Feb 05, 2015 at 10:58:39AM +0100, Jean Delvare wrote:
> On Mon, 17 Nov 2014 11:36:35 +0000, Leif Lindholm wrote:
> > Has anyone looked into using the /sys/firmware/dmi (CONFIG_DMI_SYSFS)
> > interface rather than /dev/mem?
> 
> I took a quick look and I have to say I don't like
> the /sys/firmware/dmi interface. I don't even understand how something
> like that was accepted in the kernel. It is exposing half-decoded
> information to user-space. Plugging dmidecode on top of it would
> require writing extra code specifically to parse this half-decoded
> information. And performance-wise, having to read a directory to look
> for the entries and then opening several hundred files is really not
> appealing.

Just use the library, and you won't have to see it ;)

> > (And /sys/firmware/acpi for ACPI.)
> 
> Not sure why you mention that, as dmidecode doesn't care about ACPI at
> all?

Purely for context. Not suggesting ACPI is relevant to dmidecode.

On ARM systems, without a predictable physical memory map, directly
using /dev/mem is a _really_ bad idea - so at least for ARM server
systems, we need to get to the point where we can shut /dev/mem off
completely.
 
> > Looking around, I find at least several (possibly many) projects doing
> > /dev/mem scanning for DMI/SMBIOS. If DMI_SYSFS is an acceptable way to
> > go, would anyone object to it being an external library as opposed to
> > part directly of this project?
> 
> The sole fact that you think it would require a library to
> make /sys/firmware/dmi usable by user-space tools is IMHO a good hint
> that the interface is screwed up.

The library is not suggested because of some massive complexity, but
to be able to reuse the code in many existing software packages.
dmidecode is currently safe on x86, EFI systems with SMBIOS, and
unsafe on any other system. This is a lot better than the average
package out there.

> I'd rather have the kernel export the 2 relevant memory chunks through
> sysfs as raw, binary blobs. That way dmidecode could just fetch these
> instead of reading from /dev/mem. This approach would require minimum
> changes to dmidecode. I think Ivan Khoronzhuk (Cc'd) is actually
> working on this?

No, he's done the implementation on dmi-sysfs, returning a buffer you
can use the way you already expect to parse it. Which is why the
majority of his patch set is refactoring existing code.

/
    Leif