#202 Remove old oprofile kernel module code


The upstream linux kernels have had oprofile support for many years. At this point there is little reason keeping the oprofile/module code in the user-space oprofile.


  • Maynard Johnson

    Maynard Johnson - 2011-10-04

    Will, thanks again for putting this patch together. The attached patch looks fine, but it's not quite complete. There are a lot of doc changes that are needed, too (mostly in the manual, but the oprofile man page as well). As a matter of fact, there are so many changes needed, that it's probably easier for me to make the changes myself rather than write them down here and ask you to make them. I'll work up a doc patch and attach it to this bug for you to review.

    Also, regarding the image-path stuff for finding 2.6 kernel modules. . . If we're not supporting older kernels anymore, should we default to /lib/modules/`uname -r` unless a different path is passed in by the user? The downside is that if the user of an oprofile post-processing tool is booted with a different kernel than what was used to collect the raw profile data, we would silently attribute samples to (possibly) wrong kernel modules. This probably doesn't happen very often. If we highlight this in the man pages, do you think such a default behavior would be OK? I could go either way.

    If we decide to make such a change in default behavior for locating kernel modules, we would need to scrub the man pages for various tools, which currently say something to the effect of "This is needed to find modules in kernels 2.6 and upwards". This would have to be changed to read something like "This is needed to find the correct kernel modules in use at the time of profiling." I think this whole "image-path" issue could be handled via a separate bug since it's not really dependent on the old kernel module code -- it's just tangentially related. What do you think?

  • Maynard Johnson

    Maynard Johnson - 2011-10-19
    • assigned_to: nobody --> maynardj
    • status: open --> open-fixed
  • Maynard Johnson

    Maynard Johnson - 2011-10-19

    Will and I reviewed each others patches and ack'ed them, so I committed the patches to the shared git repo today. Marking this as "Fixed".

  • Maynard Johnson

    Maynard Johnson - 2012-08-27
    • status: open-fixed --> closed-fixed

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

No, thanks