Message-Id: <200706031830.33115.lenb@kernel.org>
Date:	Sun, 3 Jun 2007 18:30:32 -0400
From:	Len Brown <lenb@...nel.org>
To:	trenn@...e.de
Cc:	linux-acpi <linux-acpi@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	penberg@...helsinki.fi
Subject: Re: [PATCH] ACPI Debug - for test, devel and possibly even for production kernels

Hello Thomas,

I'm delighted that you feel that the ACPI debug code is worthy
of being enabled by default in SuSE Linux.  While that certainly
wasn't the intent of the code, I'm open to your suggestions should
you find any issues with it where it doesn't suite your needs.

However, I have no plans to enable CONFIG_ACPI_DEBUG upstream by default.
For I don't expect it to increase the quality of bug reports we receive,
or to foster more participation and support in the community for debugging Linux/ACPI.
Indeed, I believe that end-users want fewer ACPI messages, not more.

I believe that there is a small group of people who are simultaneously
capable and willing to debug the Linux Kernel and AML.
These people already run custom built kernels and can enable CONFIG_ACPI_DEBUG
at will.  I don't believe that enabling it by default in a distribution
kernel has measurable utility for the users and customers outside this
(already served) small group.

Re: bugzilla 7122 and 5534
I do not believe that these are valid examples of where enabling
CONFIG_ACPI_DEBUG by default would have resulted in solution sooner.
While it is true that my team has more ready access to Intel hardware,
I became so alarmed at these failures that I purchased an HP nx2125
and an HP nx6325 to figure out what the HP BIOS developers were thinking.

The nx6325 is now working perfectly -- I test kernels on it almost every day.
The nx6125 is for Alexy, but unfortunately, it seems to be mired
in Russian red tape at the moment.

Regarding the % of AML that Linux is currently taking advantage of.
With a few notable exceptions, Linux is actually ahead of Microsoft
in support for the very latest version of the ACPI specification.
This, of course, is a hollow victory, as vendors don't ship features
that can't be handled by Windows.  But the point is that Linux is leading
here, not following, in support of AML.

Regarding platform specific drivers that use AML.
Everybody appreciates the efforts of the guys that are doing
these drivers -- they make our Linux laptops more useful.
But without vendor support, this requires a heroic effort.

The strategy of SuSE as a Linux distributor should not be
to escalate this heroic effort -- but to make it unnecessary.
Ie. If Brand-X wants to be certified on SuSE, then Brand-X
should provide the appropriate platform specific driver for
Linux  - or support the community with documentation so we can
do it methodically and reliably.

BTW, you mentioned WMI..
I've prototyped a Linux WMI driver, and will release it as soon as
it is in a form where people in addition to just me will find it useful --
probably in July. 

Re: timing
I'd love to be able to check stuff in upstream at any point in the release cycle,
but the reality is that Linus has ACPI on a pretty short leash.
He makes the rules, and I do my best to follow them.
After -rc1 closes, the focus is really on fixing regressions,
and patches which are worthy enough that they'd qualify
for the .stable criteria.  So in this case, we are firmly
past 2.6.22 and into 2.6.23.  Like you, I hope that happens
sooner rather than later.

Note that your earlier version of this patch is already in acpi-test.
I'll try out your update as soon as I return from watching the
Boston Red Sox clobber the New York Yankees at Fenway Park tonight.

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists