RE: [PATCH v2] ACPI: Cleanup <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> inclusions.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-owner@xxxxxxxxxxxxxxx] On Behalf Of Rafael J. Wysocki
> Sent: Wednesday, November 27, 2013 8:29 AM
> 
> On Tuesday, November 26, 2013 03:29:05 PM Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 26, 2013 at 09:29:33PM +0100, Rafael J. Wysocki wrote:
> > > On Tuesday, November 26, 2013 01:21:15 PM Lv Zheng wrote:
> > > > Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
> > > > <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions.
> > > >
> > > > First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
> > > > should not be included directly from any files that are built for
> > > > CONFIG_ACPI unset, because that generally leads to build warnings about
> > > > undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
> > > > <linux/acpi.h> includes those files and for !CONFIG_ACPI it provides stub
> > > > ACPI symbols to be used in that case.
> > > >
> > > > Second, there are ordering dependencies between those files that always
> > > > have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
> > > > prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
> > > > latter depends on are always there.  And <acpi/acpi.h> which provides
> > > > basic ACPICA type declarations should always be included prior to any other
> > > > ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
> > > > <linux/acpi.h> as appropriate.
> > > >
> > > > This patch also includes necessary cleanups in the affected files where
> > > > other ACPI headers is also included but not referenced.
> > > >
> > >
> > > This looks OK to me, but it touches several other subsystems.  It's better to
> > > CC such things to linux-kernel at least.
> > >
> > > Peter, Matthew, Tony, Konrad, Greg, Bjorn, do you have any objections against this?
> >
> > CC-ing Boris and David here.
> >
> > I presume the proper compilation tests to make sure they do compile properly
> > has been done.
> 
> Yes and we're going to run it through the auto build machinery anyway.

Hi, Rafael

The revision 1 is written in the style that it wouldn't introduce regressions as:
<acpi/acpi.h> <acpi/acpi_bus.h> <acpi/acpi_drivers.h> is replaced by <linux/acpi.h>.  If there are 2 or more linux/acpi.h inclusions in the same files, then the latter ones are deleted.
And it gets building/booting tested by enabling the affected modules for testing on x86 and x86_64.
The checker enabled tests only showed line number differences.
For special IA64 only modules, they are tested using "make <dirname of file>/<basename of file>.o" with necessary -D passed through command line.

I the revision 2, there are <asm/xxx.h> order changes, it thus may introduce regressions if there are tricks we don't know better than the original authors.
My build tests still showed no issues, but we could feed them a coverage test.
Rafael, hope you can help me do this in your bleeding-edge branch and feel free to modify the commit to fix the issues caused by such tricks.

Thanks and best regards
-Lv

> 
> Thanks,
> Rafael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f





[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux