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: <20150826150637.GF26643@krava.brq.redhat.com>
Date:	Wed, 26 Aug 2015 17:06:37 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	Jiri Olsa <jolsa@...nel.org>, lkml <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Raphaƫl Beamonte <raphael.beamonte@...il.com>
Subject: Re: [PATCH 05/11] perf tools: Move tracing_path stuff under same
 namespace

On Wed, Aug 26, 2015 at 11:58:55AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Aug 26, 2015 at 04:48:36PM +0200, Jiri Olsa escreveu:
> > On Wed, Aug 26, 2015 at 11:42:11AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Aug 26, 2015 at 03:46:47PM +0200, Jiri Olsa escreveu:
> > > > Renaming all functions touching tracing_path under same
> > > > namespace. New interface is:
> > > 
> > > But we were trying to have debugfs stuff in tools/lib/api/fs/, so that
> > > it could eventually be used by some other tools, etc, and now we're
> > > going the other way around, de-librarifying, not good :-\
> > 
> > well this gathers tracefs/debugfs together, the api/fs/{trace|debug}fs
> > are just building blocks
> > 
> > I only moved the debugfs__strerror_open_tp out of the debugfs object
> > because it needs to be one layer up, because it needs to touch tracefs
> > as well
> 
> Why not leave it there, since, for historical reasons, what is tracefs
> now was something implemented inside debugfs, so having that special
> case in debugfs__strerror_open_tp():
> 
>                 if (!access(debugfs_mountpoint, R_OK) && strncmp(filename, "tracing/", 8) == 0) {
> 
> Is ok, since tools will need to deal with older kernels, etc.
> 
> But ok, I see your point, we should rename it to something like
> tracepoint__strerror_open_definition(), so as to detach this from
> "debugfs" _and_ "tracefs", pseudo-filesystem based DWARF-like stuff
> (event definitions), but then why not have that somewhere in
> tools/lib/api/tracepoint/.

no problem with moving it over to the lib

how about having api/fs/tpfs
                 or     eventsfs
                 or     tracingfs


doing the same as tracing_path* stuff ATM

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