[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jean Delvare
Subject: Re: [dmidecode] [Patch 0/4] dmidecode: add dmi sysfs support
Date: Thu, 26 Feb 2015 18:24:18 +0100

Hi Leif,

Le Thursday 26 February 2015 à 16:29 +0000, Leif Lindholm a écrit :
> On Thu, Feb 26, 2015 at 03:48:22PM +0100, Jean Delvare wrote:
> > 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 time taken to review the patches is not an issue.
> The bit where my initial message asking what type of implementation
> you might prefer was ignored, combined with the reply to the patches
> we sent 3 months later basically saying "don't do it like that" felt
> slightly less than productive.

I admit I should have been replying faster to your initial inquiry.
Please accept my apologies again. But there's only that much time I can
devote to side projects and dmidecode is almost never at the top of my
priority list. There's a reason why I passed the official maintainer hat
to Anton several years ago :-(

> > 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.
> The problem is that we're not just looking at dmidecode. We are
> looking at many different tools. And there really isn't much point in
> us going back and changing kernel interfaces before we know if
> whatever that turns into is going to be acceptable to them.
> Hence the library.
> So, sorry, but I can't guarantee anything at this point.

Can you tell more about these other tools? I admit that I am surprised
to learn that many tools parse /dev/mem directly to extract DMI
information (if that's what you are saying.) I would expect tools in
need of DMI information to either call dmidecode and parse its output,
or use libsmbios, or read from /sys/devices/virtual/dmi/id (as for
example sensors-detect does), or read from /sys/firmware/dmi/entries.

> But we'll come back when we have at least some vague agreement from
> a few more projects on how to progress.

All tools may not have the same needs, so a unique solution may not fit
the bill. It's entirely possible that your library would be useful for
some tools, I don't know. I'm only speaking for dmidecode because that's
what I am familiar with. I can imagine how the dmi_get_*entry*()
functions could be useful (although I'd be surprised if libsmbios
doesn't already offer that.) All I'm saying really is that the
dmi_get_table() function is a nonsense from a technical perspective,
because if you need the raw table then you don't want to go through
dmi-sysfs's "entries" interface.

Jean Delvare
SUSE L3 Support

reply via email to

[Prev in Thread] Current Thread [Next in Thread]