Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 May 2003 12:32:58 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/contrib/dev/acpica acconfig.h acenv.h acfreebsd.h acgcc.h acpi.h acpiosxf.h acpixf.h acutils.h dbcmds.c dbxface.c exfldio.c exsystem.c hwsleep.c psparse.c rscreate.c tbget.c utglobal.c
Message-ID:  <20030501193258.GB778@athlon.pn.xcllnt.net>
In-Reply-To: <XFMail.20030501143516.jhb@FreeBSD.org>
References:  <200304291911.h3TJB0E2076851@repoman.freebsd.org> <XFMail.20030501143516.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 01, 2003 at 02:35:16PM -0400, John Baldwin wrote:
> 
> >   Modified files:
> >     sys/contrib/dev/acpica acconfig.h acenv.h acfreebsd.h acgcc.h 
> >                            acpi.h acpiosxf.h acpixf.h acutils.h 
> >                            dbcmds.c dbxface.c exfldio.c exsystem.c 
> >                            hwsleep.c psparse.c rscreate.c tbget.c 
> >                            utglobal.c 
> 
> This hunk looks bogus as it didn't change during the Intel import:
*snip*
> Without this change make kernel-depend of LINT gives a _lot_ of
> warnings.  LINT also doesn't compile, but this is at least a
> good first step.

Unrelated to the change (hence removed), but related to ACPI CA
contributed code:

There's a bug in the code that uninstalls ACPI tables. We have a
fix for this on the ia64 branch. Thanks to Peter. It's been forgotten,
but it would be nice to have this fix in as it hosed machines with
multiple SSDT tables. This is not specific to ia64.

Of course, since this is contributed code we should get it fixed
at the source and it will find its way back to use with the next
upgrade. However, since the 0424 snapshot had problems, the first
possible upgrade would be end May, provided the problems have
been resolved.

The question: do people think we should try to get another ACPI
snapshot in (provided we have someone willing to do it) and thus
try to get it fixed the "official" way or are we ok with changing
contrib'd code in this case and revert to the vendor branch when
we do upgrade sometime after 5.1?

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501193258.GB778>