mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-21 00:42:16 +00:00
9e827dd00a
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.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
LKML-Reference: <1257911467-28276-6-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
33 lines
975 B
C
33 lines
975 B
C
#ifndef __PERF_DATAMAP_H
|
|
#define __PERF_DATAMAP_H
|
|
|
|
#include "event.h"
|
|
#include "header.h"
|
|
|
|
typedef int (*event_type_handler_t)(event_t *, unsigned long, unsigned long);
|
|
|
|
struct perf_file_handler {
|
|
event_type_handler_t process_sample_event;
|
|
event_type_handler_t process_mmap_event;
|
|
event_type_handler_t process_comm_event;
|
|
event_type_handler_t process_fork_event;
|
|
event_type_handler_t process_exit_event;
|
|
event_type_handler_t process_lost_event;
|
|
event_type_handler_t process_read_event;
|
|
event_type_handler_t process_throttle_event;
|
|
event_type_handler_t process_unthrottle_event;
|
|
int (*sample_type_check)(u64 sample_type);
|
|
unsigned long total_unknown;
|
|
};
|
|
|
|
void register_perf_file_handler(struct perf_file_handler *handler);
|
|
int mmap_dispatch_perf_file(struct perf_header **pheader,
|
|
const char *input_name,
|
|
int force,
|
|
int full_paths,
|
|
int *cwdlen,
|
|
char **cwd);
|
|
int perf_header__read_build_ids(int input, off_t file_size);
|
|
|
|
#endif
|