On Thursday 26 February 2009 02:00:01 pm Len Brown wrote: > On Tue, 24 Feb 2009, Bjorn Helgaas wrote: > > What would you think of "drivers/acpi/internal.h"? > > better. > > I do like internal.h better than ospm.h because internal.h > sounds like something that drivers should not include, > while ospm.h sounds like something they should include. Yep, I can agree with that. > The murkyness right now I think is because we still have two > different types of code in drivers/acpi/ > > acpi/ seems to be where we have some infrastructre code, > plus some "acpi drivers", such as battery.c that use the > infrastructure to implement OS policy. Maybe we should > have the infrastructure and the drivers in two different > directories? Yes, maybe so. We certainly don't have drivers under drivers/pci just because they happen to call pci_register_driver(). drivers/platform/x86 obviously isn't the right place for generic things like battery.c, fan.c, etc, but I'd be happy if they were moved out of drivers/acpi someday. Bjorn > acpi/acpica/ is a single place for the ACPICA C-code > and has its own private headers down there, finally. > > include/linux/acpi.h > this is what other parts of the kernel use to talk > to the acpi sub-system > > include/acpi/ > this is here so that the above can include <acpi/acpi.h> > which bundles various public ACPICA headers > there is probably a more elegant way to do this. > > drivers/platform/x86/ > platform specific drivers that use acpi > rather than implement acpi, finally moved out > of the drivers/acpi/ directory -- 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