lkml.org 
[lkml]   [2009]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] perf tools: Add a new generic section in perf.data

* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> On Fri, Oct 16, 2009 at 09:10:46AM +0200, Ingo Molnar wrote:
> >
> > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> >
> > > +/*
> > > + * Version 0: contains trace_info section only
> > > + */
> > > +struct perf_file_additionals {
> > > + u64 version;
> > > + struct perf_file_section trace_info;
> > > +};
> >
> > i dont disagree with the change - but it would be even nicer to simply
> > define a features bitmask, instead of a flat version - and add the
> > trace_info section as a feature.
> >
> > That way it's all a lot more manageable: we dont know about versions per
> > se, we know about features. Individual features could be developed (and
> > backported) in a distributed way - without having to worry about a flat
> > version model.
> >
> > So i'd suggest something like a bitmask in the perf.data file header:
> >
> > DECLARE_BITMAP(features, 256);
> >
> > Plus every perf version knows about the features it supports:
> >
> > DECLARE_BITMAP(features_supported, 256);
> >
> > The compatibility rule is: perf only touches attributes that belong to
> > features it knows about.
> >
> > Ingo
>
>
> Yeah, I've thought about that too but feared about the limitation of
> bitweight(u64), although it's probably enough, we never know. That
> said I can take a bunch of four u64 to draw this bitmap and 256
> features is enough.
>
> Indeed that's way much better as a bitmap. Will do that instead.

Yeah, but please reuse linux/bitmap.h instead of some open-coded array
of 4x u64's.

Ingo


\
 
 \ /
  Last update: 2009-10-16 09:49    [from the cache]
©2003-2011 Jasper Spaans