[de78e3]: HACKING  Maximize  Restore  History

Download this file

119 lines (77 with data), 3.7 kB

And when you drive for hours, arrive to find you nowhere gone, you've just been
mouthing "brum, brum", rocking wheel, of course you have, the heap is rusted
through and off the road since you drove drunk through thirteen school yards,
laughing like Prescott.

Then welcome, ah, oo costrinzi welcome, in OProfile.

Please talk to the list before starting on something. We're not too scary.

Here's a short list of some stuff you need to know to get started. Don't forget
to read doc/CodingStyle

Source organisation


	The 2.4 module code. Sub-directories contain architecture-specific code.


	The 2.4 daemon which writes the kernel data to the sample files.


	The 2.5+ daemon


	Scripts for managing the daemon etc.


	User and developer documentation


	Classes for handling profiles


	The post-profiling tools for showing results


	op_import and its ABI support library


	The sample file access library


	C language oprofile-specific helper stuff


	A simple C++ library for parsing command lines


	Generic helpers


	The GUI for starting oprofile


You'll need autoconf 2.13+ and automake 2.5+ when using CVS. Don't forget to
autogen.sh first.

We still currently support gcc 2.91.66. Please bear this in mind.

Making patches, commit rights

Patches should be in diff -u format, appliable by patch -p1 in the top-level
source directory. Patches should not include changes to generated files.

Even trivial patches must have a change log entry in the usual format (see
ChangeLog). Refer to bug numbers in the change log if relevant.

If you make a change visible to the user in some way, you should check the
website for any needed changes. Patches to oprofile-www CVS are preferred
but a notification of what needs changing is good enough. Any changes that
affect the docs (man-pages or oprofile.xml) must include documentation updates
as appropriate.

You may after a while be given direct commit rights. You should be subscribed
to both the main list and the commits mailing list if you do. Your cvs commit
message only needs to briefly describe what your change does - the change log
should have the detailed description. Any non-trivial change needs approval
from either John or Phil, unless stated otherwise. The CVS tree will freeze
occassionally for release, in which case no commits are allowed at all without
agreement of John and Phil. CVS admin changes (-kb, .cvsignore etc.) do not
need a change log, and neither does changes to TODO. If you make a change
that affects the user (feature improvement, new feature, bug fix, UI change),
see the next section.

The oprofile website

The oprofile website source is stored in the oprofile-www CVS module, excepting
the doc/ and srcdoc/ directories, which are updated by hand at release time.
The visible website (http://oprofile.sf.net/) must always describe the last
*released* version of OProfile, but the CVS contents should be up to date with
the CVS code. This means that if you make a user-visible change as described
in the last section, you should update the files in oprofile-www and commit.
You can do "cvs update" in home/groups/o/op/oprofile/htdocs/cvs on sourceforge
to get http://oprofile.sf.net/cvs/, so you can check your changes work (and
validate: see http://www.htmlhelp.com/tools/validator/).

Any user-visible change should have a short description in the file
release-notes/release-<nextversion> in the oprofile-www CVS module.
Do not document bug fixes that were not in the last released version.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks