Re: [dmidecode] dmidecode should omit warning about SMBIOS version when -q is set

[Jean Delvare]

Hi Anton,

Le Wednesday 19 March 2014 à 18:45 +0100, Anton Arapov a écrit :
> On Mon, Mar 17, 2014 at 01:58:40PM +0100, Anton Arapov wrote:
> > On Mon, Mar 17, 2014 at 10:24:45AM +0100, Jens Rosenboom wrote:
> > > Am 16.03.14 16:36, schrieb Petter Reinholdtsen:
> > > > [Jens Rosenboom]
> > > >> As in particular scripts call dmidecode often with -s (implying -q)
> > > >> and expect to get only a single word (and in particular only a
> > > >> single line of output), I propose that in this case the warning
> > > >> about an unsupported SMBIOS version should be ommited. Most scripts
> > > >> won't be able to handle the warning properly anyway, also most -s
> > > >> options should still continue to work. My patch would look like
> > > >> this:
> > > > What about sending the warning to stderr instead?  This way scripts
> > > > looking on stdin will not notice, while the info is still emitted.
> > > Would be fine for me.
> > 
> > It's not an error message, it's INFO message. All the error
> > messages are already routed to stderr. This very message is
> > intentionally left to stdout because it IS important. And it can be
> > easily filtered out in a shell scripts.

To be fair, I would call it a warning message. Of course it can be
filtered out, but only if people expect the message, and that's
typically not the case until it's too late. And even if filtering is
easy, it's even easier (and more efficient) to not require filtering
where it doesn't make sense or can be avoided.

> > The message is important because we can't guarantee the output is
> > correct in that case. If we suppress it we might be getting reports of
> > the wrong information interpretation. IOW users will complaint about
> > all kind of weirdness dmidecode might show them when use new hardware.

I beg to disagree. As a general rule SMBIOS specifications are backward
compatible and new versions merely add fields and values. Incompatible
changes are thankfully rare, the only one I can remember of at the
moment is the UUID byte order rules.

Old versions of dmidecode should work just fine on new DMI tables when
it comes to option -s at least. This is what the original poster (Jens)
really cares about. Thus at the very least I think we should omit the
warning message if opt.string is set.

> > I am not going to fix it. :)

Me, I would like to.

Note that the message starts with hash marks. All other messages which
start with a hash mark are omitted in quiet mode [1]. Thus for
consistency I believe it would make sense to also omit that one in quiet
mode. In other words, I would apply Jens's patch.

If we really can't agree on that, then let's please at least omit it in
string mode, to make scripter's lives easier.

As a side note: developers and admins should know that most useful DMI
strings are available under Linux from sysfs for a long time now, with
most strings being even available to non-root users. This might be a
more efficient (albeit arguably less portable) way to get the
information you need.

[1] With one exception in legacy_decode, which is clearly an overlook as
it diverges from smbios_decode, so I'll fix it right now.

> And I forgot to mention:
> See the commit:
> http://cvs.savannah.gnu.org/viewvc/dmidecode/man/dmidecode.8?root=dmidecode&r1=1.24&r2=1.25
> 
> I've added it a while back to address exactly this situation.  

Documenting is always good, no matter where the warning message goes or
in which conditions it is printed. Thanks for doing that :-)

-- 
Jean Delvare
SUSE L3 Support