linux-kernel - RE: [PATCH 02/27] ACPICA: Utilities: Deploy ACPI_DEBUGGER_EXEC for ACPI

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] [day] [month] [year] [list]

Message-ID: <1AE640813FDE7649BE1B193DEA596E880255A0E9@SHSMSX101.ccr.corp.intel.com>
Date:	Tue, 6 May 2014 13:54:53 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	Pavel Machek <pavel@....cz>
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>,
	"Moore, Robert" <robert.moore@...el.com>
Subject: RE: [PATCH 02/27] ACPICA: Utilities: Deploy ACPI_DEBUGGER_EXEC for
 ACPI_DEBUGGER enabled code in utglobal.c.

Hi,

> From: Pavel Machek [mailto:pavel@....cz]
> Sent: Tuesday, May 06, 2014 7:08 PM
> 
> Hi!
> 
> > > From: Pavel Machek [mailto:pavel@....cz]
> > > Sent: Tuesday, May 06, 2014 3:54 PM
> > >
> > > On Wed 2014-04-30 10:03:39, Lv Zheng wrote:
> > > > This patch deploys ACPI_DEBUGGER_EXEC usage to utglobal.c to reduce "ifdef"
> > > > of ACPI_DEBUGGER.  No functional changes.  Lv Zheng.
> > > >
> > > > Signed-off-by: Lv Zheng <lv.zheng@...el.com>
> > > > Signed-off-by: Bob Moore <robert.moore@...el.com>
> > > > ---
> > > >  drivers/acpi/acpica/utglobal.c |    4 +---
> > > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/acpica/utglobal.c b/drivers/acpi/acpica/utglobal.c
> > > > index f3abeae..825b064 100644
> > > > --- a/drivers/acpi/acpica/utglobal.c
> > > > +++ b/drivers/acpi/acpica/utglobal.c
> > > > @@ -377,9 +377,7 @@ acpi_status acpi_ut_init_globals(void)
> > > >  	acpi_gbl_disable_mem_tracking = FALSE;
> > > >  #endif
> > > >
> > > > -#ifdef ACPI_DEBUGGER
> > > > -	acpi_gbl_db_terminate_threads = FALSE;
> > > > -#endif
> > > > +	ACPI_DEBUGGER_EXEC(acpi_gbl_db_terminate_threads = FALSE);
> > > >
> > > >  	return_ACPI_STATUS(AE_OK);
> > >
> > > Is it just me or is this incredibly ugly?
> >
> > This patch is no-op for Linux kernel.
> > ACPI_DEBUGGER is not enabled for Linux kernel.
> >
> > This patch is here to reduce the source code differences between
> > Linux and ACPICA.
> 
> > ACPICA release is done by a set of conversion utilities, the process is known as linuxizing.
> > The generation result of the linuxizing will require more human
> > interventions if such differences grow bigger.
> 
> You don't have to do the change to the original ACPICA release, do
> you?

There are many ACPI_DEBUGGER_EXEC() invocations already in the ACPICA source base, this is just a follow up to use the existing mechanism.

> 
> Would it be feasible to modify your linuxizing scripts to simply
> delete #ifdefs that can not happen for linux?

Currently there is no such mechanism.
If it is allowed and urgent, I'll try to add it. Thanks for the suggestion.
This might be happen in the future, not this release cycle.

If we can talk about the future, well, IMO, there is a better way to modulize ACPICA.
For example, this code is invoked in acpi_ut_init_globals(), I do believe it should be invoked in something like acpi_db_initialize().
Then it might also be possible to make the acpi_gbl_db_terminate_threads a static global variable bound to debugger, and invisible to any other files outside of debugger.
The most important benefit might be: we are able to kill many #ifdef/#endif code in this way.
This is more like Linux style. :-)

Thanks and best regards
-Lv
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/