Messages in this thread | | | Date | Wed, 25 Jan 2012 09:01:51 -0800 | From | Greg KH <> | Subject | Re: [RFCv3 0/9] perf tool: parser generator for events parsing |
| |
On Wed, Jan 25, 2012 at 11:49:33AM +0100, Peter Zijlstra wrote: > On Tue, 2012-01-24 at 16:53 -0800, Greg KH wrote: > > > Well, what's to keep someone from exploding one of those files to go > > over the buffer size without knowing it? > > The content is known at compile time, we could put checks in. But yeah > 4k isn't that much text.. > > > Even after reading the above link, I can't really understand what this > > is being used for. As it's sysfs files, why aren't Documentation/ABI/ > > files also being created with the patch explaining it all? > > Ah, yeah, documentation, wasn't that written in C :-) > > But fair enough... Anyway, the purpose is to describe the magic bits > that go into perf_event_attr::config[012] for a particular pmu. > > Basically they're the 'hardware' bitmasks we want to export, so that > userspace can deal with sane name/value pairs. > > > Again, if at all possible, sysfs should be one value per file. Please > > NEVER create a sysfs file that requires a parser to determine what is > > going on in it. It should be a simple 'read the value' type thing. > > The whole purpose was to drive a parser :-) Anyway, is: > "config:0-7,32-35" acceptable for a single file? > > This means, the 'config' member of struct perf_event_attr bits 0-7,32-35 > form a bitfield whose name is then given by the filename that has this > content.
Yes, that would be fine.
> > So yes, multiple sysfs files do make sense, the resource load should be > > almost non-existant for new ones. > > Surely all these attribute objects take more space than a few lines of > text, but ok, I guess multiple files it is.
Great, thanks for asking.
greg k-h
| |