linux-kernel - Re: [PATCH 1/2] perf: Add persistent events

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: <20100614212426.GA19915@liondog.tnic>
Date:	Mon, 14 Jun 2010 23:24:26 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Arnaldo Carvalho de Melo <acme@...radead.org>
Cc:	Borislav Petkov <bp@...64.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Lin Ming <ming.m.lin@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] perf: Add persistent events

From: Arnaldo Carvalho de Melo <acme@...radead.org>
Date: Mon, Jun 14, 2010 at 06:01:16PM -0300

> > Right, so I started playing with this, added a global Makefile to tools/
> > and from there we descend into lib/ and perf/ in that order to prepare
> > all the modules for the perflib. I've played with the include paths so
> > that you can have #include <util/util.h> for all that generic library
> > stuff.
> > 
> > The patch below carves out the debugfs helpers along with some generic
> > headers, please take a look and let me know if this is an agreeable
> > direction I'm going. Yeah, it is big, I think vger won't be able to
> > swallow it but this is only moving files around so...
> 
> One thing I thought was that perhaps reusing Kbuild would be a good
> idea, something like:
> 
> cd tools/
> make menuconfig
> 
> And use all the Kbuild machinery to select needed features, etc.
> 
> What do you think?

Why not, however, do we need it at this point? I mean, you simply do

make -j; make install

in tools/perf/ and all is good. It even tells you if some libraries are
missing. I simply don't see such a large amount of options to justify
a configurator but maybe there are usecases where Kconfig would make
sense, hmmm?

> It can be a follow up to what you're doing, that is needed anyway, some
> questions below:
>  
> > Thanks.
> > 
> > --
> > >From 0f391f0acf39d3b2e85145dce389cbf425cb7cdd Mon Sep 17 00:00:00 2001
> > From: Borislav Petkov <borislav.petkov@....com>
> > Date: Mon, 14 Jun 2010 21:14:15 +0200
> > Subject: [PATCH] perf: rewire generic library stuff
> > 
> > ---
> >  tools/Makefile                                     |   74 +++++
> >  tools/lib/Makefile                                 |   41 +++
> >  tools/lib/util/cache.h                             |   86 ++++++
> >  tools/lib/util/debugfs.c                           |  252 +++++++++++++++++
> >  tools/lib/util/debugfs.h                           |   31 +++
> >  tools/lib/util/strbuf.c                            |  133 +++++++++
> >  tools/lib/util/strbuf.h                            |   92 +++++++
> >  tools/lib/util/types.h                             |   17 ++
> >  tools/lib/util/util.h                              |  282 ++++++++++++++++++++
> 
> Will we continue using "util" here? What other name could we pick? Nah,
> probably for the ones you moved we can continue using it, the symbols
> part I plan to move to tools/lib/symbol/.

Yeah, names are kinda arbitrary. Keeping "util" meant as little changes
as possible but it would make more sense to simply have all different
library modules under "tools/lib/<module>.(c|h)" Will do so in the next
version.

> >  tools/perf/Makefile                                |   64 +----
> >  tools/perf/bench/bench.h                           |    2 +
> >  tools/perf/bench/mem-memcpy.c                      |    2 +-
> >  tools/perf/bench/sched-messaging.c                 |    2 +-
> >  tools/perf/bench/sched-pipe.c                      |    2 +-
> >  tools/perf/builtin-bench.c                         |    2 +-
> >  tools/perf/builtin.h                               |    4 +-
> 
> > -#include "types.h"
> > +#include <util/types.h>
> 
> I thought about suggesting using -I to reduce patch size, but then it is
> using "" :-\

Yeah, I have the -I$(CURDIR)/lib for this in the top level Makefile so all
library includes would be like:

#include <util.h>

however, this does not differentiate perflib (let's call it that for how
:) from libc headers. Do we want a "perf" or "kernel" or "perflib" or
whatever prefix here - it might make sense later when this thing grows
to differentiate between the namespaces...?

> So I'll do some testing here and merge this for .36 unless somebody has
> other issues with this, Ingo? Frédéric?

Can you please wait a bit with the merging, I'd like to write the
whole rasd daemon stuff before we merge that and have the generic lib
carve-out in one patchset?

Thanks.

-- 
Regards/Gruss,
    Boris.
--
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/