lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1AE640813FDE7649BE1B193DEA596E8802556F33@SHSMSX101.ccr.corp.intel.com>
Date:	Tue, 22 Apr 2014 02:01:57 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
CC:	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Brown, Len" <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH 1/4] ACPICA: Add <acpi/platform/aclinuxxf.h> to remove
 mis-ordered inclusion of <acpi/actypes.h> from <acpi/platform/aclinux.h>.

Hi,

<skip>

> > +#define ACPI_NATIVE_INTERFACE_HEADER	<acpi/platform/aclinuxxf.h>
> 
> This is not good.
> 
> We don't do things like this in the kernel, because they are confusing and hard
> to debug if necessary, so please find a different way to make this work.

I use this extra header file to collect:
1. static inline OSL functions
2. divergences of prototypes that haven't been back ported to ACPICA.
This file is useful for ACPICA release automation.

There are the following concerns that lead to the use of this solution:
1. for this extra header file itself
    A. The new header file is OSPM specific, thus it needn't be upstreamed to ACPICA;
    B. Since it needn't be upstreamed to ACPICA, ACPICA needn't determine the name of this extra header;
    C. It has to be the last file included by <acpi/acpi.h>.
2. for the file that includes this extra header file
    A. Currently there is no OSPM specific code in <acpi/acpi.h>.
Thus I use a macro so that there is still no OSPM specific code in <acpi/acpi.h> and the name of the extra header can be determined by OSPM.

If you want another solution, is the following acceptable?
1. In <acpi/platform/aclinux.h>
    #define ACPI_INCLUDE_EXTRA_NATIVE_HEADER	1
2. In <acpi/acpi.h> <- this is an ACPICA header file, 
    #ifdef ACPI_INCLUDE_EXTRA_NATIVE_HEADER
    #include <acpi/platform/acextra.h>
    #endif
Note that in this solution, the name of the extra header file will be determined by ACPICA.

> And the name aclinuxxf.h is not one of my favourite.

Since this file needn't be upstreamed into ACPICA, could you help to determine it if the acextra.h was still not acceptable?

Thanks and best regards
-Lv

> 
> Thanks!
> 
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ