mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-24 02:10:52 +07:00
perf db-export: Add brief documentation
Add brief documentation to explain how the database export maintains backward and forward compatibility. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20190520113728.14389-15-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This commit is contained in:
parent
003ccdc716
commit
1159facee9
41
tools/perf/Documentation/db-export.txt
Normal file
41
tools/perf/Documentation/db-export.txt
Normal file
@ -0,0 +1,41 @@
|
||||
Database Export
|
||||
===============
|
||||
|
||||
perf tool's python scripting engine:
|
||||
|
||||
tools/perf/util/scripting-engines/trace-event-python.c
|
||||
|
||||
supports scripts:
|
||||
|
||||
tools/perf/scripts/python/export-to-sqlite.py
|
||||
tools/perf/scripts/python/export-to-postgresql.py
|
||||
|
||||
which export data to a SQLite3 or PostgreSQL database.
|
||||
|
||||
The export process provides records with unique sequential ids which allows the
|
||||
data to be imported directly to a database and provides the relationships
|
||||
between tables.
|
||||
|
||||
Over time it is possible to continue to expand the export while maintaining
|
||||
backward and forward compatibility, by following some simple rules:
|
||||
|
||||
1. Because of the nature of SQL, existing tables and columns can continue to be
|
||||
used so long as the names and meanings (and to some extent data types) remain
|
||||
the same.
|
||||
|
||||
2. New tables and columns can be added, without affecting existing SQL queries,
|
||||
so long as the new names are unique.
|
||||
|
||||
3. Scripts that use a database (e.g. exported-sql-viewer.py) can maintain
|
||||
backward compatibility by testing for the presence of new tables and columns
|
||||
before using them. e.g. function IsSelectable() in exported-sql-viewer.py
|
||||
|
||||
4. The export scripts themselves maintain forward compatibility (i.e. an existing
|
||||
script will continue to work with new versions of perf) by accepting a variable
|
||||
number of arguments (e.g. def call_return_table(*x)) i.e. perf can pass more
|
||||
arguments which old scripts will ignore.
|
||||
|
||||
5. The scripting engine tests for the existence of script handler functions
|
||||
before calling them. The scripting engine can also test for the support of new
|
||||
or optional features by checking for the existence and value of script global
|
||||
variables.
|
Loading…
Reference in New Issue
Block a user