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.