All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Starikovskiy <astarikovskiy@suse.de>
To: "Moore, Robert" <robert.moore@intel.com>
Cc: Len Brown <lenb@kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"bjorn.helgaas@hp.com" <bjorn.helgaas@hp.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Lin, Ming M" <ming.m.lin@intel.com>
Subject: Re: ACPICA header files
Date: Sat, 18 Oct 2008 21:42:16 +0400	[thread overview]
Message-ID: <48FA1FF8.1090806@suse.de> (raw)
In-Reply-To: <4911F71203A09E4D9981D27F9D830858032E0739@orsmsx503.amr.corp.intel.com>

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@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> Sent: Friday, October 17, 2008 2:50 PM
> To: Len Brown
> Cc: Dugger, Donald D; linux-acpi@vger.kernel.org; bjorn.helgaas@hp.com; akpm@linux-foundation.org; astarikovskiy@suse.de; 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@vger.kernel.org [mailto:linux-acpi-
>> owner@vger.kernel.org] On Behalf Of Len Brown
>> Sent: Friday, October 17, 2008 1:55 PM
>> To: Moore, Robert
>> Cc: Dugger, Donald D; linux-acpi@vger.kernel.org; bjorn.helgaas@hp.com;
>> akpm@linux-foundation.org; astarikovskiy@suse.de; 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@vger.kernel.org
>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2008-10-18 17:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-17 14:49 [PATCH] Fix possible null ptr dereference donald.d.dugger
2008-10-17 16:44 ` Len Brown
2008-10-17 18:02 ` Moore, Robert
2008-10-17 20:55   ` Len Brown
2008-10-17 21:49     ` Moore, Robert
2008-10-18 16:33       ` ACPICA header files Moore, Robert
2008-10-18 17:42         ` Alexey Starikovskiy [this message]
2008-10-18 21:05           ` Moore, Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48FA1FF8.1090806@suse.de \
    --to=astarikovskiy@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=donald.d.dugger@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=robert.moore@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.