Messages in this thread | | | Date | Thu, 24 Jul 2014 11:02:56 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: [PATCH 13/52] perf tools: Add perf_pmu__scan_file() |
| |
Em Thu, Jul 24, 2014 at 12:06:06PM +0200, Jiri Olsa escreveu: > On Wed, Jul 23, 2014 at 11:25:25AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Jul 23, 2014 at 11:36:38AM +0200, Jiri Olsa escreveu: > > > On Wed, Jul 23, 2014 at 09:24:49AM +0300, Adrian Hunter wrote: > > > > On 07/22/2014 10:09 PM, Jiri Olsa wrote: > > > > > On Tue, Jul 22, 2014 at 04:17:22PM +0300, Adrian Hunter wrote: > > > > > > > > > > SNIP > > > > > > > > > >> + > > > > >> +static FILE *perf_pmu__open_file(struct perf_pmu *pmu, const char *name) > > > > >> +{ > > > > >> + struct stat st; > > > > >> + char path[PATH_MAX]; > > > > >> + const char *sysfs; > > > > >> + > > > > >> + sysfs = sysfs__mountpoint(); > > > > >> + if (!sysfs) > > > > >> + return NULL; > > > > >> + > > > > >> + snprintf(path, PATH_MAX, > > > > >> + "%s" EVENT_SOURCE_DEVICE_PATH "%s/%s", sysfs, pmu->name, name); > > > > >> + > > > > >> + if (stat(path, &st) < 0) > > > > >> + return NULL; > > > > >> + > > > > >> + return fopen(path, "r"); > > > > >> +} > > > > > > > > > > looks like this function could be used in pmu_cpumask and pmu_type > > > > > and maybe others > > > > > > > > There is existing code duplication between them. Given the large number of > > > > patches I would say it is easier to deal with that separately. > > > > > > ook, jirka > > > > Is this an Acked-by: jirka? > > well, while perf_pmu__open_file would be handy now, perf_pmu__scan_file > does now have any callers in the patchset.. > > I'm not sure whats our current policy one this ;-) as I've seen more > functions like this over this patchset, I think we should not introduce > new interface without caller
Its a huge patchkit, with some bits non trivial, reducing it s size so that the most hairy bits can stand out seems like a good approach at this point. :-)
- Arnaldo
| |