Re: [dmidecode] [Patch 0/4] dmidecode: add dmi sysfs support

[Leif Lindholm]

On Thu, Feb 26, 2015 at 12:02:54PM +0100, Jean Delvare wrote:
> > > I do not want to have an extra depenendency on libmifs too. dmidecode
> > > as a tool meant to be self-sufficient. We might want to get the dmifs
> > > implementation into dmidecode.
> > >
> > > Jean, what is your opinion here?
> 
> I thought I had replied already but the list archive is pretty positive
> that it only happened in my dreams. Sorry about that. So I am replying
> now for completeness, even though I will just repeat what I said in
> other threads earlier today.
> 
> I agree with Anton, I don't want to depend on a library either. Firstly
> because dmidecode was meant to be independent from the beginning, and
> secondly (most importantly) because requiring a library is a clear
> indication that you are doing something wrong.

This was never about "requiring a library". This was about the 57
different projects (possible exaggeration, but it is certainly in the
double digits) that all want to be independent and now all need
to be changed.

> Getting the data you need from sysfs instead of /dev/mem is a good move
> IMHO, and I will support that. But all you need in order to achieve
> that is to let the kernel code export the entry point and the DMI table
> as binary files. Plugging dmidecode on top of that should be pretty
> straightforward and should certainly not take a 4-patch set plus a
> library.

Exporting the entry point is also not quite as straigtforward as you
suggest. SMBIOS 3 adds a new entry point format, which can legally
point to the same DMI table as the legacy SMBIOS entry point - or not.
In which case we need to at the very least export one blob for each
entry point and then have dmidecode pick one.

Refactoring dmidecode, with a however-many-patches set will be
required regardless.

The other issue with shifting the responsibility to a kernel patch,
which I realise might not be much of a priority for you, is that we
will still be unable to use dmidecode on ARM platforms for a
substantial period of time (certainly too late for 4.0)...

/
    Leif