Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 01 May 2003 16:11:48 -0400 (EDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Marcel Moolenaar <marcel@xcllnt.net>
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:  <XFMail.20030501161148.jhb@FreeBSD.org>
In-Reply-To: <20030501193258.GB778@athlon.pn.xcllnt.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On 01-May-2003 Marcel Moolenaar wrote:
> 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?

We have had files in ACPI land pulled off the branch before, so I
think that if it's a major showstopper for 5.1 it can just be
committed.  I would send the patch to the acpi-jp@ list.  The Intel
guys follow it and are quite responsive to good bug reports and/or
patches.

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/



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