dmidecode mails.

dmidecode mails.

[Dave Jones]

The last month or so, we've seen lots of people posting
their dmidecode output here (in response to seeing requests
for it in dmesg, if their BIOS requests _OSI(Linux) I guess)

I'm wondering if anyone is actually looking at these, because
I don't think I've seen a single follow up to any of them.

Given we're about to do a Fedora release with this printk,
I'm contemplating removing it, because we're going to be
getting them for a long time after upstream removed the printk
otherwise.  Unless someone sees value in continuing to get
the reports ?

	Dave

-- 
http://www.codemonkey.org.uk

Re: dmidecode mails.

[Len Brown]

On Saturday 13 October 2007 13:48, Dave Jones wrote:
> The last month or so, we've seen lots of people posting
> their dmidecode output here (in response to seeing requests
> for it in dmesg, if their BIOS requests _OSI(Linux) I guess)
> 
> I'm wondering if anyone is actually looking at these, because
> I don't think I've seen a single follow up to any of them.

I plan to follow up on every one of them -- just
that until today, there always seemed to be something more urgent:-)

> Given we're about to do a Fedora release with this printk,
> I'm contemplating removing it, because we're going to be
> getting them for a long time after upstream removed the printk
> otherwise.  Unless someone sees value in continuing to get
> the reports ?

Either way is fine with me -- the e-mail will
come directly here rather than to the fedora project.

The latest code is smarter -- not asking for stuff it already
knows about (big DMI list on the way)
and printing directly to dmesg rather than asking
for dmidecode output.
I'll send the latest code to .25-rc8 and also .23-stable,
but .22 will be as it always was.

So far, I've found that this hook is usually a NOP,
but the cases where it is not are important.

We have to get rid of it, so slogging through the escapes
to see where the problems are really can't be avoided.

thanks,
-Len