cvs commit: src/sys/dev/acpica acpi.c acpi_resource.c acpivar.h

[M. Warner Losh]

In message: <412BC4C5.3000708 at root.org>
            Nate Lawson <nate at root.org> writes:
: David O'Brien wrote:
: > On Tue, Aug 24, 2004 at 12:25:29PM -0700, Nate Lawson wrote:
: > 
: >>David O'Brien wrote:
: >>
: >>>On Mon, Aug 23, 2004 at 04:28:42PM +0000, Nate Lawson wrote:
: >>>
: >>>
: >>>>njl         2004-08-23 16:28:42 UTC
: >>>>FreeBSD src repository
: >>>>Modified files:
: >>>>  sys/dev/acpica       acpi.c acpi_resource.c acpivar.h 
: >>>>Log:
: >>>>Rework sysresource management.  Instead of having each sysresource object
: >>>
: >>>...
: >>>
: >>>
: >>>>Tested by:      Pawel Worach <sajd_at_telia.com>
: >>>>Tested by:      Radek Kozlowski <radek_at_raadradd.com>
: >>>
: >>>
: >>>Tested only on i386, right??
: >>
: >>Still waiting for the amd64 laptop donation.  ;-)  In any case, I've 
: >>just committed a fix.  The amd64,ia64 nexus hadn't been caught up with 
: >>i386 and the resource code depends on the new method.
: > 
: > In the future, may I make a request that you post patches for large
: > changes before committing them?  Now that ACPI is a multi-platform thing
: > that is very basic to booting, we have to be careful about changes to it.
: 
: For large commits (i.e. mpsafe patch), I post patches and get testing. 
: For critical bugfixes like this, I get the reporter to test after I test 
: and then commit.  With the minimum MFC period, I want to get critical 
: bugfixes into HEAD as soon as they are tested (to start the clock) and 
: plan to be responsive to any subsequent bug reports.

But to introduce a guaranteed core dump on non-i386 architectures is
not acceptible.  By rushing things in, you have inconvenienced many
users of these platforms (amd64 is getting quite popular), which
reduces the developer's time for further FreeBSD work since they have
to deal with the core dump, track it down, etc.  ACPI is so central to
the system that such breakages should be avoided to the greatest
extent possible.

Warner