Re: [dmidecode] /sys/firmware interface?

[Jean Delvare]

On Thu, 5 Feb 2015 11:11:07 +0000, Leif Lindholm wrote:
> 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 ;)

A library won't solve any of these problems. The code will be somewhere
else, but it will be just as awkward and slow. Plus, someone will have
to take care of packaging this library on all systems which currently
have dmidecode. For openSUSE and SLE that would be me. Also I can't
imagine what kind of API the library would offer, that we could use
without a significant amount of new code in dmidecode anyway.

> (...)
> 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.

Oh, I'm already convinced. Reading from /dev/mem was done just because
it worked and there was nothing better at the time. I'm all for getting
the data from somewhere else when possible.

> > > 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.

This reminds me of libsysfs, which finally died when people realized
that sysfs itself is already an API and adding another one on top of it
doesn't add any value. If the API offered by sysfs is inadequate, it
must be improved. If the API offered by sysfs is sane then there's no
code to factor out to a library.

Anyway, if you really want to go the library route, there's libsmbios,
just write any application you want on top of it. dmidecode is a
different project.

> > (...)
> > 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.

I don't understand the difference with what I said :-/ Oh well, I'll
just have to read Ivan's code and then I can make better comments.

-- 
Jean Delvare
SUSE L3 Support