2. Locating and creating sample files

We have a sample value and its satellite data stored in a struct transient, and we must locate an actual sample file to store the sample in, using the context information in the transient structure as a key. The transient data to sample file lookup is handled in daemon/opd_sfile.c. A hash is taken of the transient values that are relevant (depending upon the setting of --separate, some values might be irrelevant), and the hash value is used to lookup the list of currently open sample files. Of course, the sample file might not be found, in which case we need to create and open it.

OProfile uses a rather complex scheme for naming sample files, in order to make selecting relevant sample files easier for the post-profiling utilities. The exact details of the scheme are given in oprofile-tests/pp_interface, but for now it will suffice to remember that the filename will include only relevant information for the current settings, taken from the transient data. A fully-specified filename looks something like :


It should be clear that this identifies such information as the application binary, the dependent (library) binary, the hardware event, and the process and thread ID. Typically, not all this information is needed, in which cases some values may be replaced with the token all.

The code that generates this filename and opens the file is found in daemon/opd_mangling.c. You may have realised that at this point, we do not have the binary image file names, only the dcookie values. In order to determine a file name, a dcookie value is looked up in the dcookie cache. This is to be found in daemon/opd_cookie.c. Since dcookies are both persistent and unique during a sampling session, we can cache the values. If the value is not found in the cache, then we ask the kernel to do the lookup from value to file name for us by calling lookup_dcookie(). This looks up the value in a kernel-side cache (see fs/dcookies.c) and returns the fully-qualified file name to userspace.