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]
Date:	Fri, 22 May 2015 19:33:19 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc:	ak@...ux.intel.com, linux-kernel@...r.kernel.org,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	mingo@...hat.com, Paul Mackerras <paulus@...ba.org>,
	namhyung@...nel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 2/4] perf: jevents: Program to convert JSON file to C
 style file

On Fri, May 22, 2015 at 08:58:22AM -0700, Sukadev Bhattiprolu wrote:

SNIP

> | 
> | there's no concetion (yet) in the new build system to trigger
> | another binery build as a dependency for object file.. I'd
> | rather do this the framework way, please check attached patch
> | 
> | also currently the pmu-events.c is generated every time,
> | so we need to add the event json data files as dependency
> 
> pmu-events.c depends only on JSON files relevant to the arch perf is
> being built on and there could be several JSON files per arch. So it
> would complicate the Makefiles.
> 
> Besides, didn't we conclude that the cost of generating pmu-events.c
> during build is negligible ?

yes, but only when it's necessary.. if there's no change in definitions
and we already have pmu-events.o built.. why rebuild?

> |  
> | -libperf-y += pmu-events/
> |  libperf-y += util/
> |  libperf-y += arch/
> |  libperf-y += ui/
> | diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> | index 57e46a541686..a4ba451cffa2 100644
> | --- a/tools/perf/Makefile.perf
> | +++ b/tools/perf/Makefile.perf
> | @@ -272,14 +272,29 @@ strip: $(PROGRAMS) $(OUTPUT)perf
> |  
> |  PERF_IN := $(OUTPUT)perf-in.o
> |  
> | +JEVENTS       := $(OUTPUT)pmu-events/jevents
> | +JEVENTS_IN    := $(OUTPUT)pmu-events/jevents-in.o
> | +PMU_EVENTS_IN := $(OUTPUT)pmu-events/pmu-events-in.o
> 
> I will try this out, but why not just add pmu-events.o to libperf?

this is related to my first comment:

	> | there's no concetion (yet) in the new build system to trigger
	> | another binery build as a dependency for object file.. I'd
	> | rather do this the framework way, please check attached patch

it's not possible to trigger the application build within the Build file
in a way the framework was designed.. so it cannot easily display commands
handle dependencies etc.. just allows simple/hacky solution you did ;-)

so I separated the pmu-events.o so libperf does not have dependency
on the jevents applications, and treat it as separated object

jirka
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ