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

[Jean Delvare]

Hi Leif,

On Thu, 26 Feb 2015 13:35:14 +0000, Leif Lindholm wrote:
> On Thu, Feb 26, 2015 at 12:02:54PM +0100, Jean Delvare wrote:
> > 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.

Any project who doesn't want to reinvent the wheel should use
libsmbios. I am tired of people wanting to turn dmidecode into a
library when such a library already exists. Just use it and leave us
alone, thank you very much.

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

We don't "need" to. We may do that, or we may export a single entry
point, as is being done now. I am fine either way. But as I read the
specification, given that the table pointed to by the _SM3_ entry
point should always be a super-set of the table pointed to by the _SM_
entry point, I can't really think of a valid reason for bothering with
the latter if we have the former.

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

Nobody is questioning the fact that dmidecode will require some code
changes to be able to survive to a /dev/mem removal. But trying to make
the solution simple and fast seems like a reasonable goal.

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

Ivan's solution requires a kernel patch anyway, which isn't upstream
yet, so that makes zero difference if said patch only exports the entry
point (as it does now) or also exports the raw DMI table (as I
suggested.)

Arguments of the form "we need this upstream fast so take this patch
now and shut up" were never well received by the upstream kernel
developers, and they won't be better received by the maintainers of
other projects, including dmidecode. Code goes upstream when it is good
and ready to go there, not before. Also note that everybody can
backport patches to older kernel branches if they want to, so arguments
of the form "I need this in that kernel version" don't hold either.

I know that I took a long time to review the patches and post my
comments and I am sorry about that. But you'd rather be patient when
working with other people in the open source community. We are all busy
and our priorities don't necessarily match your priorities.

The only question left is whether you are going to implement the
changes I suggested now and get things working fast, or if you are
going to ignore my request and I have to do it all by myself, which
won't possibly happen before April given my current schedule. That's
your call, really.

-- 
Jean Delvare
SUSE L3 Support