From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Adrian Hunter <adrian.hunter@intel.com>,
Corey Ashford <cjashfor@linux.vnet.ibm.com>,
David Ahern <dsahern@gmail.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>, Namhyung Kim <namhyung@kernel.org>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 1/3] perf tools: Factor sysfs code into generic fs object
Date: Tue, 5 Nov 2013 14:07:29 +0100 [thread overview]
Message-ID: <20131105130729.GD1071@krava.brq.redhat.com> (raw)
In-Reply-To: <20131105124814.GA5539@infradead.org>
On Tue, Nov 05, 2013 at 10:48:14AM -0200, Arnaldo Carvalho de Melo wrote:
SNIP
> > +struct perf_fs {
>
> Ditch the 'perf', make it plain 'struct fs'.
>
> > + const char *name;
> > + const char * const *mounts;
> > + char path[PATH_MAX + 1];
> > + bool found;
> > + long magic;
> > +};
> > +
> > +enum {
> > + FS_SYSFS = 0,
>
> FS__SYSFS
>
> > +};
> > +
> > +static struct perf_fs fss[] = {
>
> Funny name, perhaps fs__entries instead? :-)
ok, will change all above namings :)
>
> And here we have it static, at some point we could introduce a
> 'fs__register', that would be the counterpart of 'register_filesystem'
> in the kernel sources.
>
> > + [FS_SYSFS] = {
> > + .name = "sysfs",
> > + .mounts = sysfs_known_mountpoints,
> > + .magic = SYSFS_MAGIC,
> > + },
> > +};
> > +
> > +static bool read_mounts(struct perf_fs *fs)
> > +{
> > + bool found = false;
> > + char type[100];
> > + FILE *fp;
> > +
> > + fp = fopen("/proc/mounts", "r");
> > + if (fp == NULL)
> > + return NULL;
> > +
> > + while (!found &&
> > + fscanf(fp, "%*s %" STR(PATH_MAX) "s %99s %*s %*d %*d\n",
> > + fs->path, type) == 2) {
> > +
> > + if (strcmp(type, fs->name) == 0)
> > + found = true;
> > + }
> > +
> > + fclose(fp);
> > + return fs->found = found;
> > +}
>
> This is not a per instance method, I to traverse /proc/mounts once,
> checking all entries in 'fs__entries' marking the ones that are present,
> i.e. fs__entries would be a list/tree of 'struct fs'.
>
> > +static int valid_mount(const char *fs, long magic)
> > +{
> > + struct statfs st_fs;
> > +
> > + if (statfs(fs, &st_fs) < 0)
> > + return -ENOENT;
> > + else if (st_fs.f_type != magic)
> > + return -ENOENT;
> > +
> > + return 0;
> > +}
>
> Now this is getting me confused, so we will have to traverse
> /proc/mounts looking for that .name to be what we expect in entries and
> afterwards we do a second step, checking if the magic number is the one
> expected? Can't we do both verifications in just one place?
the valid_mount is called only for preconfigured
(known mountpoints) paths
>
> I know you haven't written this code, is just generalizing, but I got
> confused so had to comment on it :-\
yep ;-) perhaps some init code could do that
>
> Perhaps since you're just making it useful for more filesystems just
> please address the 'perf_fs' naming suggestions and we can deal with
> these other issues later?
ok, I have already changes for the 3/3 change,
I'll send it together
jirka
next prev parent reply other threads:[~2013-11-05 13:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 11:06 [PATCH 0/3] perf tools: Add perf_event_max_sample_rate freq check Jiri Olsa
2013-11-04 11:06 ` [PATCH 1/3] perf tools: Factor sysfs code into generic fs object Jiri Olsa
2013-11-05 12:48 ` Arnaldo Carvalho de Melo
2013-11-05 13:07 ` Jiri Olsa [this message]
2013-11-05 14:55 ` Arnaldo Carvalho de Melo
2013-11-04 11:06 ` [PATCH 2/3] perf tools: Add procfs support into " Jiri Olsa
2013-11-04 11:06 ` [PATCH 3/3] perf tools: Check maximum frequency rate for record/top Jiri Olsa
2013-11-04 15:17 ` David Ahern
2013-11-04 15:32 ` Jiri Olsa
2013-11-04 17:56 ` Arnaldo Carvalho de Melo
2013-11-04 19:01 ` [PATCH 0/3] perf tools: Add perf_event_max_sample_rate freq check Jiri Olsa
2013-11-05 14:14 [PATCHv2 " Jiri Olsa
2013-11-05 14:14 ` [PATCH 1/3] perf tools: Factor sysfs code into generic fs object Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131105130729.GD1071@krava.brq.redhat.com \
--to=jolsa@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=dsahern@gmail.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome