Right. We would change acpi.h to only pull in the public headers. This would only break code that is cheating. -----Original Message----- From: Alexey Starikovskiy [mailto:astarikovskiy@xxxxxxx] Sent: Saturday, October 18, 2008 10:42 AM To: Moore, Robert Cc: Len Brown; Dugger, Donald D; linux-acpi@xxxxxxxxxxxxxxx; bjorn.helgaas@xxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; Lin, Ming M Subject: Re: ACPICA header files The problem with linux acpi headers is that all drivers include <linux/acpi.h>, which will include private headers. We need to remove all private headers from this public one. Moore, Robert wrote: > The actual "public" acpica headers are: > > acexcep.h // ACPICA exceptions > actypes.h // ACPICA data types > actbl.h // ACPI table definitions > acpixf.h // Prototypes for ACPICA interfaces (host-to-ACPICA) > acpiosxf.h // Prototypes for OSL interfaces (ACPICA-to-host) > > And the entire contents of the include/platform directory > > Would it make sense (would it be helpful) to leave these public headers in the current acpi include directory and to move everything else to a new directory? > > How about include/internal. > > We could keep the existing acpi.h file and have it only pull in the files above, so the disruption to existing acpica users would be minimal. The only code that would be affected would be code that is cheating by using ACPICA internal interfaces. > > It may be the case that some internal functions are actually useful to the ACPI-related device drivers. I don't have any issue with making these interfaces public (and beefing up the parameter validation, etc.) > > Comments? > Thanks, > Bob > > > > -----Original Message----- > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-owner@xxxxxxxxxxxxxxx] On Behalf Of Moore, Robert > Sent: Friday, October 17, 2008 2:50 PM > To: Len Brown > Cc: Dugger, Donald D; linux-acpi@xxxxxxxxxxxxxxx; bjorn.helgaas@xxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; astarikovskiy@xxxxxxx; Lin, Ming M > Subject: RE: [PATCH] Fix possible null ptr dereference > > It's on the TBD list. > > Not true that everything includes everything, however. But everything is in the same directory. > > How would you organize things? > > >> -----Original Message----- >> From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Len Brown >> Sent: Friday, October 17, 2008 1:55 PM >> To: Moore, Robert >> Cc: Dugger, Donald D; linux-acpi@xxxxxxxxxxxxxxx; bjorn.helgaas@xxxxxx; >> akpm@xxxxxxxxxxxxxxxxxxxx; astarikovskiy@xxxxxxx; Lin, Ming M >> Subject: RE: [PATCH] Fix possible null ptr dereference >> >> >>> In general, the internal ACPICA functions do not perform nearly as much >> parameter validation as the external functions. The Host OS should not be >> calling any of the ACPICA internal functions for this and a few other good >> reasons -- such as the fact that internal functions can disappear, be >> renamed, or have the parameters changed without warning at any time. >>> It would probably be a good idea to audit Linux for the use of internal >> ACPICA functions and fix these bugs. >> >> I think the way to do this is to clean up the headers >> so that code outside of ACPICA doesn't even see >> the declarations of the internal ACPICA functions. >> >> Right now everything includes everything, so the headers can't help us. >> >> -Len >> -- >> 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 > -- > 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 -- 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
