lkml.org 
[lkml]   [2009]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Exporting kmemleak.h to userspace
    On Thu, Sep 3, 2009 at 6:34 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
    > On Thu, 2009-09-03 at 14:18 +0100, Catalin Marinas wrote:
    >> On Thu, 2009-09-03 at 09:23 +0300, Pekka Enberg wrote:
    >> > On Thu, Sep 3, 2009 at 3:29 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
    >> > > I was reviewing kmemleak code and noticed kmemleak.h went exported to
    >> > > userspace under include/linux/kmemleak.h. Do we expect userspace to
    >> > > use this stuff somehow? All relevant kmemleak structs are kept
    >> > > private, I'm curious what userspace apps would use this.
    >> >
    >> > AFAICT, nobody. Catalin, why is the header exported?
    >>
    >> I haven't done anything specifically to export it. It probably gets
    >> included via other files. Is adding #ifdef __KERNEL__ enough to avoid
    >> this problem?
    >
    > It should be exported only if it's listed in Kbuild,

    What do you mean by that?

    > which it isn't. Luis?

    Well I see kmemleak on

    Kernel hacking -->
    [*] Kernel memory leak detector

    but its not clear to me by what you mean by that it should be exported
    only if its listed in Kbuild.

    Anyway my point was that userspace does not need kmemleak.h and we are
    providing it to userspace. Unfortunately I really am not sure what the
    alternative is, it seems we tend to export to userspace a lot of other
    kernel headers which userspace does not use. For networking we have
    private header space for example on include/net/ but for general
    kernel stuff is there an alternative? Should there be? Or as Catalin
    mentions should we just use #ifdef __KERNEL__ for headers we do not
    want to export to userspace?

    Luis


    \
     
     \ /
      Last update: 2009-09-03 20:03    [W:8.364 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site