Messages in this thread | | | Subject | Re: [PATCH 6/6] perf tools: Bring linear set of section headers for features | From | Peter Zijlstra <> | Date | Wed, 11 Nov 2009 07:20:04 +0100 |
| |
On Wed, 2009-11-11 at 04:51 +0100, Frederic Weisbecker wrote: > Build a set of section headers for features right after the datas. > Each implemented feature will have one of such section header that > provides the offset and the size of the data manipulated by the feature. > > The trace informations have moved after the data and are recorded > on exit time. > > The new layout is as follows: > > ----------------------- > ___ > [ magic ] | > [ header size ] | > [ attr size ] | > [ attr content offset ] | > [ attr content size ] | > [ data offset ] File Headers > [ data size ] | > [ event_types offset ] | > [ event_types size ] | > [ feature bitmap ] v > > [ attr section ] > [ events section ] > > ___ > [ X ] | > [ X ] | > [ X ] Datas > [ X ] | > [ X ] v > > ___ > [ Feature 1 offset ] | > [ Feature 1 size ] Features headers > [ Feature 2 offset ] | > [ Feature 2 size ] v > > [ Feature 1 content ] > [ Feature 2 content ] > ----------------------- > > We have as many feature's section headers as we have features in use for > the current file. > > Say Feat 1 and Feat 3 are used by the file, but not Feat 2. Then the > feature headers will be like follows: > > [ Feature 1 offset ] | > [ Feature 1 size ] Features headers > [ Feature 3 offset ] | > [ Feature 3 size ] v > > There is no hole to cover Feature 2 that is not in use here. We only > need to cover the needed headers in order, from the lowest feature bit > to the highest. > > Currently we have two features: HEADER_TRACE_INFO and HEADER_BUILD_ID. > Both have their contents that follow the feature headers. Putting the > contents right after the feature headers is not mandatory though. > While we keep the feature headers right after the data and in order, > their offsets can point everywhere. We have just put the two above > feature contents in the end of the file for convenience. > > The purpose of this layout change is to have a file format that scales > while keeping it simple: having such linear feature headers is less > error prone wrt forward/backward compatibility as the content of a > feature can be put anywhere, its location can even change by the > time, it's fine because its headers will tell where it is. And we know > how to find these headers, following the above rules.
Does do mess up append though... be sure to add some magic for that.
| |