[RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address) - Kernel

This is a discussion on [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address) - Kernel ; > For example, we're about to do unwinding/stack-traces of userspace > programs. To what extent do you think the kernel unwinder (should one > reappear in git) would welcome patches that provide zero benefit to > the kernel, but only ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 40 of 40

Thread: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

  1. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    > For example, we're about to do unwinding/stack-traces of userspace
    > programs. To what extent do you think the kernel unwinder (should one
    > reappear in git) would welcome patches that provide zero benefit to
    > the kernel, but only enable a peculiar (nonintrusive) sort of
    > unwinding we would need for complex userspace stacks?


    In theory if the tables are right you don't need any special
    for the kernel dwarf2 unwinder. If the tables are not right
    fix them.

    I believe oprofile did this already in some cases (generating
    user back traces from the kernel)

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    On Fri, 2008-07-18 at 09:02 -0400, Frank Ch. Eigler wrote:
    > Peter Zijlstra writes:
    >
    > > [...]
    > >> Right now x86 doesn't really have a good reliable unwinder that
    > >> works without frame pointer. I think systemtap
    > >> recently switched to Jan Beulich's dwarf2 unwinder. Before
    > >> switching to the in kernel unwinder that one would need to be
    > >> re-merged again.

    > >
    > > Those are two separate issues.
    > >
    > > 1) stap ought to use the kernel's infrastructure and not re-implement
    > > its own.
    > > 2) if the kernel's infrastructure doesn't meet requirements, improve
    > > it.

    >
    > They are related to the extent that readers may not realize some
    > implications of systemtap being/becoming a *kernel-resident* but not
    > *kernel-focused* tool.
    >
    > For example, we're about to do unwinding/stack-traces of userspace
    > programs. To what extent do you think the kernel unwinder (should one
    > reappear in git) would welcome patches that provide zero benefit to
    > the kernel, but only enable a peculiar (nonintrusive) sort of
    > unwinding we would need for complex userspace stacks?


    I think sysprof (kernel/trace/trace_sysprof.c) already does user-space
    stack unwinding. So pushing that capability further up the chain when a
    second user (stap) comes along makes perfect sense.



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    On Fri, 2008-07-18 at 09:02 -0400, Frank Ch. Eigler wrote:
    > Peter Zijlstra writes:
    >
    > > [...]
    > >> Right now x86 doesn't really have a good reliable unwinder that
    > >> works without frame pointer. I think systemtap
    > >> recently switched to Jan Beulich's dwarf2 unwinder. Before
    > >> switching to the in kernel unwinder that one would need to be
    > >> re-merged again.

    > >
    > > Those are two separate issues.
    > >
    > > 1) stap ought to use the kernel's infrastructure and not re-implement
    > > its own.
    > > 2) if the kernel's infrastructure doesn't meet requirements, improve
    > > it.

    >
    > They are related to the extent that readers may not realize some
    > implications of systemtap being/becoming a *kernel-resident* but not
    > *kernel-focused* tool.
    >
    > For example, we're about to do unwinding/stack-traces of userspace
    > programs. To what extent do you think the kernel unwinder (should one
    > reappear in git) would welcome patches that provide zero benefit to
    > the kernel, but only enable a peculiar (nonintrusive) sort of
    > unwinding we would need for complex userspace stacks?


    I'm not entirely convinced systemtap wants full stack unwinding in the
    kernel. What the kernel wants is the call trace, which it can do with
    kallsyms. However, systemtap in userspace sees all the relevant dwarf
    information as well ... it could do a much better job of unwinding: give
    file and line and arguments for function calls, for instance. All it
    really needs is to have the relevant pieces of the stack relayed back.

    James


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    Hi -

    On Fri, Jul 18, 2008 at 03:10:27PM +0200, Peter Zijlstra wrote:
    > [...]
    > > For example, we're about to do unwinding/stack-traces of userspace
    > > programs. To what extent do you think the kernel unwinder (should one
    > > reappear in git) would welcome patches that provide zero benefit to
    > > the kernel, but only enable a peculiar (nonintrusive) sort of
    > > unwinding we would need for complex userspace stacks?

    >
    > I think sysprof (kernel/trace/trace_sysprof.c) already does user-space
    > stack unwinding. So pushing that capability further up the chain when a
    > second user (stap) comes along makes perfect sense.


    trace_sysprof relies on dump_stack, which is x86-only and does not do
    elf/dwarf unwinding proper. (Likewise oprofile, etc.) They can't
    even start, because they don't have unwind data available - something
    we plan to make available to the systemtap runtime.


    - FChE
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    Peter Zijlstra writes:
    >
    > I think sysprof (kernel/trace/trace_sysprof.c) already does user-space
    > stack unwinding. So pushing that capability further up the chain when a
    > second user (stap) comes along makes perfect sense.


    oprofile call trace profiling also does it.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    Hi -

    On Fri, Jul 18, 2008 at 08:21:24AM -0500, James Bottomley wrote:

    > [...] I'm not entirely convinced systemtap wants full stack
    > unwinding in the kernel.


    Sure we "want" it if we can get it. It enables richer data gathering.
    It lets scripts act on the contents of the call stack ("is this probe
    being run due to a callback from this or that shared library?").


    > [...] However, systemtap in userspace sees all the relevant dwarf
    > information as well ... it could do a much better job of unwinding:
    > give file and line and arguments for function calls, for instance.
    > All it really needs is to have the relevant pieces of the stack
    > relayed back.


    The relevant bits of stack for a userspace program could include
    several megabytes per thread; without unwind info we can't be sure
    which parts are which. (A full gdb symbolic backtrace takes seconds
    to compute - something we can't possibly afford in situ.)


    - FChE
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    On Thu, 2008-07-17 at 17:36 -0400, Masami Hiramatsu wrote:
    > James Bottomley wrote:
    > > On Thu, 2008-07-17 at 09:18 -0500, James Bottomley wrote:
    > >> OK, thought about it. There seem to be two possible solutions
    > >>
    > >> 1. Get systemtap always to offset from non-static functions. This
    > >> will use the standard linker to ensure uniqueness (a module
    > >> qualifier will still need to be added to the struct kprobe for
    > >> lookup, since modules can duplicate unexported kernel symbols).
    > >> 2. Add the filename as a discriminator for duplicate symbols in the
    > >> kallsyms program (would still need module qualifier). This is
    > >> appealing because the path name would be printed in the kernel
    > >> trace to help with oops tracking
    > >>
    > >> This is where negotiations come in. To me 2. looks to be better because
    > >> it will help us with oops tracking. On the other hand, it's usually
    > >> pretty obvious from the stack trace context which files the duplicate
    > >> symbols are actually in; what do other people think?

    > >
    > > Just by way of illustration, this is systemtap fixed up according to
    > > suggestion number 1. You can see now using your test case that we get:
    > >
    > > # probes
    > > kernel.function("do_open@fs/block_dev.c:929") /* pc= */ /* <- kernel.function("do_open") */
    > > kernel.function("do_open@fs/nfsctl.c:24") /* pc= */ /* <- kernel.function("do_open") */
    > > kernel.function("do_open@ipc/mqueue.c:642") /* pc= */ /* <- kernel.function("do_open") */

    >
    > Hi James,
    >
    > Thank you for updating the patch.
    > Unfortunately, I found another scenario; if someone make a module which
    > has EXPORT_SYMBOL(do_open), it's a non-static function. but there are
    > other static version do_open in kallsyms.
    > Here, I tested it and got below;
    >
    > $ stap --kelf -e 'probe module("test").function("do_open"){}' -p2
    > # probes
    > module("test").function("do_open@?") /* pc= */ /* <- module("test").function("do_open") */


    OK, I fixed this. It turns out that kprobes already had a syntax for
    this problem; it's : (in fact it won't work without
    this). I updated the code (attached below) to work correctly. I'm
    still looking at the kallsyms code for a uniqueness solution.

    James

    ---

    From: James Bottomley
    Subject: Part1 use symbol_name/offset to locate dwarf probes

    ---
    tapsets.cxx | 120 ++++++++++++++++++++++++++++++++++++++++------------------
    1 files changed, 83 insertions(+), 37 deletions(-)

    diff --git a/tapsets.cxx b/tapsets.cxx
    index a08a8ab..f24dc10 100644
    --- a/tapsets.cxx
    +++ b/tapsets.cxx
    @@ -491,6 +491,7 @@ func_info
    Dwarf_Addr entrypc;
    Dwarf_Addr prologue_end;
    bool weak;
    + bool global;
    // Comparison functor for list of functions sorted by address. The
    // two versions that take a Dwarf_Addr let us use the STL algorithms
    // upper_bound, equal_range et al., but we don't know whether the
    @@ -591,6 +592,7 @@ symbol_table
    module_info *mod_info; // associated module
    map map_by_name;
    vector list_by_addr;
    + vector global_list_by_addr;
    typedef vector::iterator iterator_t;
    typedef pair range_t;
    #ifdef __powerpc__
    @@ -598,7 +600,7 @@ symbol_table
    #endif
    // add_symbol doesn't leave symbol table in order; call
    // symbol_table::sort() when done adding symbols.
    - void add_symbol(const char *name, bool weak, Dwarf_Addr addr,
    + void add_symbol(const char *name, bool weak, bool global, Dwarf_Addr addr,
    Dwarf_Addr *high_addr);
    void sort();
    enum info_status read_symbols(FILE *f, const string& path);
    @@ -611,7 +613,7 @@ symbol_table
    void purge_syscall_stubs();
    func_info *lookup_symbol(const string& name);
    Dwarf_Addr lookup_symbol_address(const string& name);
    - func_info *get_func_containing_address(Dwarf_Addr addr);
    + func_info *get_func_containing_address(Dwarf_Addr addr, bool global);

    symbol_table(module_info *mi) : mod_info(mi) {}
    ~symbol_table();
    @@ -2309,13 +2311,15 @@ struct dwarf_derived_probe: public derived_probe
    const string& module,
    const string& section,
    Dwarf_Addr dwfl_addr,
    - Dwarf_Addr addr,
    + string symbol,
    + unsigned int offset,
    dwarf_query & q,
    Dwarf_Die* scope_die);

    string module;
    string section;
    - Dwarf_Addr addr;
    + string kprobe_symbol;
    + unsigned int kprobe_offset;
    bool has_return;
    bool has_maxactive;
    long maxactive_val;
    @@ -2840,7 +2844,7 @@ dwarf_query::query_module_symtab()
    // Find the "function" in which the indicated address resides.
    Dwarf_Addr addr =
    (has_function_num ? function_num_val : statement_num_val);
    - fi = sym_table->get_func_containing_address(addr);
    + fi = sym_table->get_func_containing_address(addr, false);
    if (!fi)
    {
    cerr << "Warning: address "
    @@ -3265,9 +3269,18 @@ dwarf_query::add_probe_point(const string& funcname,

    if (! bad)
    {
    + struct module_info *mi = dw.mod_info;
    + if (!mi->sym_table)
    + mi->get_symtab(this);
    + struct symbol_table *sym_tab = mi->sym_table;
    + func_info *symbol = sym_tab->get_func_containing_address(addr, true);
    +
    sess.unwindsym_modules.insert (module);
    probe = new dwarf_derived_probe(funcname, filename, line,
    - module, reloc_section, addr, reloc_addr, *this, scope_die);
    + module, reloc_section, reloc_addr,
    + symbol->name,
    + (unsigned int)(addr - symbol->addr),
    + *this, scope_die);
    results.push_back(probe);
    }
    }
    @@ -4385,7 +4398,8 @@ dwarf_derived_probe:rintsig (ostream& o) const
    // function instances. This is distinct from the verbose/clog
    // output, since this part goes into the cache hash calculations.
    sole_location()->print (o);
    - o << " /* pc=0x" << hex << addr << dec << " */";
    + o << " /* pc=<" << kprobe_symbol << "+0x" << hex
    + << kprobe_offset << dec << "> */";
    printsig_nested (o);
    }

    @@ -4411,22 +4425,26 @@ dwarf_derived_probe::dwarf_derived_probe(const string& funcname,
    // NB: dwfl_addr is the virtualized
    // address for this symbol.
    Dwarf_Addr dwfl_addr,
    - // addr is the section-offset for
    - // actual relocation.
    - Dwarf_Addr addr,
    + // symbol is the closest known symbol
    + // and offset is the offset from the symbol
    + string symbol,
    + unsigned int offset,
    dwarf_query& q,
    Dwarf_Die* scope_die /* may be null */)
    : derived_probe (q.base_probe, new probe_point(*q.base_loc) /* .components soon rewritten */ ),
    - module (module), section (section), addr (addr),
    + module (module), section (section), kprobe_symbol(symbol),
    + kprobe_offset(offset),
    has_return (q.has_return),
    has_maxactive (q.has_maxactive),
    maxactive_val (q.maxactive_val)
    {
    // Assert relocation invariants
    +#if 0
    if (section == "" && dwfl_addr != addr) // addr should be absolute
    throw semantic_error ("missing relocation base against", q.base_loc->tok);
    if (section != "" && dwfl_addr == addr) // addr should be an offset
    throw semantic_error ("inconsistent relocation address", q.base_loc->tok);
    +#endif

    this->tok = q.base_probe->tok;

    @@ -4634,8 +4652,8 @@ dwarf_derived_probe_group::emit_module_decls (systemtap_session& s)
    // Let's find some stats for the three embedded strings. Maybe they
    // are small and uniform enough to justify putting char[MAX]'s into
    // the array instead of relocated char*'s.
    - size_t module_name_max = 0, section_name_max = 0, pp_name_max = 0;
    - size_t module_name_tot = 0, section_name_tot = 0, pp_name_tot = 0;
    + size_t pp_name_max = 0, pp_name_tot = 0;
    + size_t symbol_name_name_max = 0, symbol_name_name_tot = 0;
    size_t all_name_cnt = probes_by_module.size(); // for average
    for (p_b_m_iterator it = probes_by_module.begin(); it != probes_by_module.end(); it++)
    {
    @@ -4644,9 +4662,8 @@ dwarf_derived_probe_group::emit_module_decls (systemtap_session& s)
    size_t var##_size = (expr) + 1; \
    var##_max = max (var##_max, var##_size); \
    var##_tot += var##_size; } while (0)
    - DOIT(module_name, p->module.size());
    - DOIT(section_name, p->section.size());
    DOIT(pp_name, lex_cast_qstring(*p->sole_location()).size());
    + DOIT(symbol_name_name, p->kprobe_symbol.size());
    #undef DOIT
    }

    @@ -4666,11 +4683,10 @@ dwarf_derived_probe_group::emit_module_decls (systemtap_session& s)
    if (s.verbose > 2) clog << "stap_dwarf_probe *" << #var << endl; \
    }

    - CALCIT(module);
    - CALCIT(section);
    CALCIT(pp);
    + CALCIT(symbol_name);

    - s.op->newline() << "const unsigned long address;";
    + s.op->newline() << "unsigned int offset;";
    s.op->newline() << "void (* const ph) (struct context*);";
    s.op->newline(-1) << "} stap_dwarf_probes[] = {";
    s.op->indent(1);
    @@ -4687,9 +4703,8 @@ dwarf_derived_probe_group::emit_module_decls (systemtap_session& s)
    assert (p->maxactive_val >= 0 && p->maxactive_val <= USHRT_MAX);
    s.op->line() << " .maxactive_val=" << p->maxactive_val << ",";
    }
    - s.op->line() << " .address=0x" << hex << p->addr << dec << "UL,";
    - s.op->line() << " .module=\"" << p->module << "\",";
    - s.op->line() << " .section=\"" << p->section << "\",";
    + s.op->line() << " .symbol_name=\"" << p->kprobe_symbol << "\",";
    + s.op->line() << " .offset=0x" << hex << p->kprobe_offset << dec << ",";
    s.op->line() << " .pp=" << lex_cast_qstring (*p->sole_location()) << ",";
    s.op->line() << " .ph=&" << p->name;
    s.op->line() << " },";
    @@ -4749,11 +4764,10 @@ dwarf_derived_probe_group::emit_module_init (systemtap_session& s)
    s.op->newline() << "for (i=0; i<" << probes_by_module.size() << "; i++) {";
    s.op->newline(1) << "struct stap_dwarf_probe *sdp = & stap_dwarf_probes[i];";
    s.op->newline() << "struct stap_dwarf_kprobe *kp = & stap_dwarf_kprobes[i];";
    - s.op->newline() << "unsigned long relocated_addr = _stp_module_relocate (sdp->module, sdp->section, sdp->address);";
    - s.op->newline() << "if (relocated_addr == 0) continue;"; // quietly; assume module is absent
    s.op->newline() << "probe_point = sdp->pp;";
    s.op->newline() << "if (sdp->return_p) {";
    - s.op->newline(1) << "kp->u.krp.kp.addr = (void *) relocated_addr;";
    + s.op->newline(1) << "kp->u.krp.kp.symbol_name = sdp->symbol_name;";
    + s.op->newline(1) << "kp->u.krp.kp.offset = sdp->offset;";
    s.op->newline() << "if (sdp->maxactive_p) {";
    s.op->newline(1) << "kp->u.krp.maxactive = sdp->maxactive_val;";
    s.op->newline(-1) << "} else {";
    @@ -4774,8 +4788,8 @@ dwarf_derived_probe_group::emit_module_init (systemtap_session& s)
    s.op->newline() << "rc = register_kretprobe (& kp->u.krp);";
    s.op->newline() << "#endif";
    s.op->newline(-1) << "} else {";
    - // to ensure safeness of bspcache, always use aggr_kprobe on ia64
    - s.op->newline(1) << "kp->u.kp.addr = (void *) relocated_addr;";
    + s.op->newline(1) << "kp->u.krp.kp.symbol_name = sdp->symbol_name;";
    + s.op->newline(1) << "kp->u.krp.kp.offset = sdp->offset;";
    s.op->newline() << "kp->u.kp.pre_handler = &enter_kprobe_probe;";
    s.op->newline() << "#ifdef __ia64__";
    s.op->newline() << "kp->dummy.addr = kp->u.kp.addr;";
    @@ -4939,12 +4953,20 @@ dwarf_builder::build(systemtap_session & sess,
    throw semantic_error ("absolute statement probe in unprivileged script", q.base_probe->tok);
    }

    + struct module_info *mi = dw->mod_info;
    + if (!mi->sym_table)
    + mi->get_symtab(&q);
    + struct symbol_table *sym_tab = mi->sym_table;
    + func_info *symbol = sym_tab->get_func_containing_address(q.statement_num_val, true);
    +
    // For kernel.statement(NUM).absolute probe points, we bypass
    // all the debuginfo stuff: We just wire up a
    // dwarf_derived_probe right here and now.
    dwarf_derived_probe* p =
    new dwarf_derived_probe ("", "", 0, "kernel", "",
    - q.statement_num_val, q.statement_num_val,
    + q.statement_num_val,
    + symbol->name,
    + (unsigned int)(q.statement_num_val - symbol->addr),
    q, 0);
    finished_results.push_back (p);
    sess.unwindsym_modules.insert ("kernel");
    @@ -4962,8 +4984,8 @@ symbol_table::~symbol_table()
    }

    void
    -symbol_table::add_symbol(const char *name, bool weak, Dwarf_Addr addr,
    - Dwarf_Addr *high_addr)
    +symbol_table::add_symbol(const char *name, bool weak, bool global,
    + Dwarf_Addr addr, Dwarf_Addr *high_addr)
    {
    #ifdef __powerpc__
    // Map ".sys_foo" to "sys_foo".
    @@ -4974,10 +4996,13 @@ symbol_table::add_symbol(const char *name, bool weak, Dwarf_Addr addr,
    fi->addr = addr;
    fi->name = name;
    fi->weak = weak;
    + fi->global = global;
    map_by_name[fi->name] = fi;
    // TODO: Use a multimap in case there are multiple static
    // functions with the same name?
    list_by_addr.push_back(fi);
    + if (global)
    + global_list_by_addr.push_back(fi);
    }

    enum info_status
    @@ -5015,7 +5040,8 @@ symbol_table::read_symbols(FILE *f, const string& path)
    break;
    }
    if (type == 'T' || type == 't' || type == 'W')
    - add_symbol(name, (type == 'W'), (Dwarf_Addr) addr, &high_addr);
    + add_symbol(name, (type == 'W'), (type == 'T'),
    + (Dwarf_Addr) addr, &high_addr);
    }

    if (list_by_addr.size() < 1)
    @@ -5134,7 +5160,8 @@ symbol_table::get_from_elf()
    if (name && GELF_ST_TYPE(sym.st_info) == STT_FUNC &&
    !reject_section(section))
    add_symbol(name, (GELF_ST_BIND(sym.st_info) == STB_WEAK),
    - sym.st_value, &high_addr);
    + GELF_ST_BIND(sym.st_info) == STB_GLOBAL,
    + sym.st_value, &high_addr);
    }
    sort();
    return info_present;
    @@ -5175,14 +5202,29 @@ symbol_table::mark_dwarf_redundancies(dwflpp *dw)
    }

    func_info *
    -symbol_table::get_func_containing_address(Dwarf_Ad dr addr)
    +symbol_table::get_func_containing_address(Dwarf_A ddr addr, bool global)
    {
    - iterator_t iter = upper_bound(list_by_addr.begin(), list_by_addr.end(), addr,
    - func_info::Compare());
    - if (iter == list_by_addr.begin())
    - return NULL;
    + iterator_t iter;
    +
    + if (global)
    + {
    + iter = upper_bound(global_list_by_addr.begin(),
    + global_list_by_addr.end(), addr,
    + func_info::Compare());
    + if (iter == global_list_by_addr.begin())
    + return NULL;
    + else
    + return *(iter - 1);
    + }
    else
    - return *(iter - 1);
    + {
    + iter = upper_bound(list_by_addr.begin(), list_by_addr.end(), addr,
    + func_info::Compare());
    + if (iter == list_by_addr.begin())
    + return NULL;
    + else
    + return *(iter - 1);
    + }
    }

    func_info *
    @@ -5235,12 +5277,16 @@ symbol_table:urge_syscall_stubs()
    list_by_addr.erase(remove(purge_range.first, purge_range.second,
    (func_info*)0),
    purge_range.second);
    + // NOTE: At the moment global_list_by_addr has no weak symbols
    + // so nothing needs to be removed from it.
    }

    void
    symbol_table::sort()
    {
    stable_sort(list_by_addr.begin(), list_by_addr.end(), func_info::Compare());
    + stable_sort(global_list_by_addr.begin(), global_list_by_addr.end(),
    + func_info::Compare());
    }

    void
    --
    1.5.6.2



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    On Thu, 17 Jul 2008 17:33:55 -0400
    "Frank Ch. Eigler" wrote:

    > Yes, that is generally desirable - each case is usually a question of
    > cost/benefit. One significant requirement for us is to keep working
    > with older kernels.


    You will have to weigh that against the benefits of making
    systemtap generally useful for kernel developers, which
    would result in a more active systemtap community and,
    eventually, more available scripts and easier end user
    functionality.

    If a project is not aimed squarely at the developers who
    could give the project critical mass, it is essentially
    doomed.

    --
    All rights reversed.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    Hi -

    On Tue, Jul 22, 2008 at 02:00:15PM -0400, Rik van Riel wrote:
    > [...]
    > > Yes, that is generally desirable - each case is usually a question of
    > > cost/benefit. One significant requirement for us is to keep working
    > > with older kernels.

    >
    > You will have to weigh that against the benefits of making
    > systemtap generally useful for kernel developers [...]


    Understood & agreed, Rik. If an issue arises where there is genuine
    conflict between kernel-developer-usability and something else, we'll
    try to solve it favouring the former if at all possible.

    (The kprobes addressing argument cannot reasonably be placed into this
    category.)


    - FChE
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    On Tue, 2008-07-22 at 14:11 -0400, Frank Ch. Eigler wrote:
    > Hi -
    >
    > On Tue, Jul 22, 2008 at 02:00:15PM -0400, Rik van Riel wrote:
    > > [...]
    > > > Yes, that is generally desirable - each case is usually a question of
    > > > cost/benefit. One significant requirement for us is to keep working
    > > > with older kernels.

    > >
    > > You will have to weigh that against the benefits of making
    > > systemtap generally useful for kernel developers [...]

    >
    > Understood & agreed, Rik. If an issue arises where there is genuine
    > conflict between kernel-developer-usability and something else, we'll
    > try to solve it favouring the former if at all possible.
    >
    > (The kprobes addressing argument cannot reasonably be placed into this
    > category.)


    You have your viewpoint inverted, if the kernel developers think you
    have a problem, and you fail to address it, they will walk away.

    If you want the kernel people to endorse your project, you'll have to
    please them. Its that simple. If that means having to radically
    re-structure your design, and/or break backwards compatibility then so
    be it. Such are the costs for not collaborating from the start.

    If you stubbornly refuse to co-operate you'll either break the project
    or invite a fork/rewrite by someone else if the idea is deemed
    worthwhile enough.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    Peter Zijlstra writes:

    > [...]
    >> > You will have to weigh that against the benefits of making
    >> > systemtap generally useful for kernel developers [...]

    >>
    >> Understood & agreed, Rik. If an issue arises where there is genuine
    >> conflict between kernel-developer-usability and something else, we'll
    >> try to solve it favouring the former if at all possible.
    >>
    >> (The kprobes addressing argument cannot reasonably be placed into this
    >> category.)


    > You have your viewpoint inverted, if the kernel developers think you
    > have a problem, and you fail to address it, they will walk away.
    >
    > If you want the kernel people to endorse your project, you'll have
    > to please them. It's that simple. [...]


    We have and will try to accomodate anything reasonable. I trust no
    one is suggesting that every systemtap-related suggestion from lkml is
    to be treated as if infallible, and that we can continue to debate the
    wisdom of each idea on its merits.

    - FChE
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    Hi -

    I wrote:

    > > [...] One significant requirement for us is to keep working with
    > > older kernels. [...]


    Maybe it's worth elaborating on why the need for backward
    compatibility is different for systemtap than for typical kernel-side
    code.

    The bulk of systemtap is a user-space program, and it does very
    user-spacey things like parsing dwarf and invoking compilers, running
    network servers. Soon it will include user-space libraries. It is so
    different from the stuff normally found there that no one has AFAIK
    seriously proposed that the entire software be made part of the kernel
    git tree. So it is an ordinary separate user-space package, built by
    users and distributors.

    It does happen to *generate* kernel modules. The way that such a
    module must interface with any particular kernel is naturally subject
    to the whims & desires of the kernel du jour. This is why we have a
    mass of mechanism to try to automatically speak to each kernel version
    as appropriate.

    It is desirable to minimize this mass for obvious reasons. When a new
    upstream kernel comes out with a tasty new feature -- or a less tasty
    API rewrite -- we need to extend systemtap to support that too. We
    cannot easily take old support away, because then the same user-space
    code base would no longer run against actually installed kernels.

    To draw an analogy, systemtap is somewhat like low-level userspace
    code like glibc or syslogd or udevd. I hope no one would seriously
    propose casually committing code to those packages that would make
    them unusable on prior kernel versions. Accepting such a patch would
    require their maintainers to fork outright every time a kernel change
    occurs.

    Things are good however if the low-level userspace changes are
    backward-compatible, so that the new kernel facility is used when
    present, but the software does not regress if it is not. I believe
    this is what we need to aim for, even though it puts the bulk of the
    burden on systemtap (or glibc, or ...).

    I hope this fills in some of the gaps in the background.


    - FChE
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    On Wed, 23 Jul 2008 11:04:34 -0400
    "Frank Ch. Eigler" wrote:

    > Hi -
    >
    > I wrote:
    >
    > > > [...] One significant requirement for us is to keep working with
    > > > older kernels. [...]

    >
    > Maybe it's worth elaborating on why the need for backward
    > compatibility is different for systemtap than for typical kernel-side
    > code.
    >
    > The bulk of systemtap is a user-space program, and it does very
    > user-spacey things like parsing dwarf and invoking compilers, running
    > network servers. Soon it will include user-space libraries. It is so
    > different from the stuff normally found there that no one has AFAIK
    > seriously proposed that the entire software be made part of the kernel
    > git tree. So it is an ordinary separate user-space package, built by
    > users and distributors.


    so far so good...

    >
    > It does happen to *generate* kernel modules. The way that such a
    > module must interface with any particular kernel is naturally subject
    > to the whims & desires of the kernel du jour. This is why we have a
    > mass of mechanism to try to automatically speak to each kernel version
    > as appropriate.


    and this is where I strongly disagree.
    THIS part *has* to be in the kernel source, so that we can change it
    WITH the kernel as we change it. If this means that there's some
    userland .so code in the kernel source, so be it. If it means we provide
    some template files that your userland fills in the blanks for, even
    better. (paint-by-number kernel modules!)

    But to have any chance at all of systemtap being sustainable, this part
    of the stack has to be together with where the changes happen.

    >
    > It is desirable to minimize this mass for obvious reasons. When a new
    > upstream kernel comes out with a tasty new feature -- or a less tasty
    > API rewrite -- we need to extend systemtap to support that too.


    At that point you are already 3 months too late for me, and probably
    for most of my fellow kernel hackers. THIS is exactly what makes
    systemtap not usable for kernel hackers, and this is exactly why you
    see very little contributions from kernel hackers.
    (and when it's seen it gets a rather luke warm reception, but that's a
    different story).

    It also means that unless I want to package and build systemtap myself,
    I have to wait for my OS vendor to think about moving to the kernel I'm
    on before I can use systemtap. For me as kernel developer.. that's the
    second show stopper already.


    > To draw an analogy, systemtap is somewhat like low-level userspace
    > code like glibc or syslogd or udevd. I hope no one would seriously
    > propose casually committing code to those packages that would make
    > them unusable on prior kernel versions. Accepting such a patch would
    > require their maintainers to fork outright every time a kernel change
    > occurs.


    we've discussed pulling udev into the kernel source several times, and
    the jury is still out on it.
    But systemtap is NOT like udev or glibc or ..
    it's a kernel component.. at least the part that generates the kernel
    code is. it needs to breathe and move together with the kernel.
    >
    > I hope this fills in some of the gaps in the background.


    it explains where you're coming from, which is good. However I for one
    really disagree with the assumption, and i just tried to point out that
    the consequences of this are rather dreadful.

    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    On Wed, 2008-07-23 at 11:04 -0400, Frank Ch. Eigler wrote:
    > Hi -
    >
    > I wrote:
    >
    > > > [...] One significant requirement for us is to keep working with
    > > > older kernels. [...]

    >
    > Maybe it's worth elaborating on why the need for backward
    > compatibility is different for systemtap than for typical kernel-side
    > code.
    >
    > The bulk of systemtap is a user-space program, and it does very
    > user-spacey things like parsing dwarf and invoking compilers, running
    > network servers. Soon it will include user-space libraries. It is so
    > different from the stuff normally found there that no one has AFAIK
    > seriously proposed that the entire software be made part of the kernel
    > git tree. So it is an ordinary separate user-space package, built by
    > users and distributors.
    >
    > It does happen to *generate* kernel modules. The way that such a
    > module must interface with any particular kernel is naturally subject
    > to the whims & desires of the kernel du jour. This is why we have a
    > mass of mechanism to try to automatically speak to each kernel version
    > as appropriate.
    >
    > It is desirable to minimize this mass for obvious reasons. When a new
    > upstream kernel comes out with a tasty new feature -- or a less tasty
    > API rewrite -- we need to extend systemtap to support that too. We
    > cannot easily take old support away, because then the same user-space
    > code base would no longer run against actually installed kernels.
    >
    > To draw an analogy, systemtap is somewhat like low-level userspace
    > code like glibc or syslogd or udevd. I hope no one would seriously
    > propose casually committing code to those packages that would make
    > them unusable on prior kernel versions. Accepting such a patch would
    > require their maintainers to fork outright every time a kernel change
    > occurs.
    >
    > Things are good however if the low-level userspace changes are
    > backward-compatible, so that the new kernel facility is used when
    > present, but the software does not regress if it is not. I believe
    > this is what we need to aim for, even though it puts the bulk of the
    > burden on systemtap (or glibc, or ...).
    >
    > I hope this fills in some of the gaps in the background.


    Why does a new version of stap have to work on ancient kernels?

    A new gnome version requires a new gtk version, a new kde version
    requires a new qt etc.. so why does a new stap not require a new kernel?

    Why isn't only supporting the last few kernels, say for example as far
    back as there are -stable series at the moment of release, good enough?

    People who insist on running stale kernels are usually the same people
    who run stale userspace - we call those enterprise people - so why can't
    they run matching stale version of the kernel and stap?

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    Arjan van de Ven writes:

    > [...]
    >> It does happen to *generate* kernel modules. The way that such a
    >> module must interface with any particular kernel is naturally subject
    >> to the whims & desires of the kernel du jour. This is why we have a
    >> mass of mechanism to try to automatically speak to each kernel version
    >> as appropriate.


    > and this is where I strongly disagree. THIS part *has* to be in the
    > kernel source, so that we can change it WITH the kernel as we change
    > it. [...] But to have any chance at all of systemtap being
    > sustainable, this part of the stack has to be together with where
    > the changes happen.


    OK. It will take us some time to figure out to what extent this would
    be feasible. Maybe a topic for Portland.


    >> It is desirable to minimize this mass for obvious reasons. When a new
    >> upstream kernel comes out with a tasty new feature -- or a less tasty
    >> API rewrite -- we need to extend systemtap to support that too.

    >
    > At that point you are already 3 months too late for me, and probably
    > for most of my fellow kernel hackers.


    (Really? Have we ever been 3 months behind supporting the git kernel?)


    > (and when it's seen it gets a rather luke warm reception, but that's
    > a different story).


    I hope the backward compatibility issue, as it stands today, helps
    explain the reasons for the current deal with kprobes.


    In the interim (before we come up with a way of moving more
    kernel-coupled systemtap code into kernel.org/git), would y'all
    consider an arrangement? Those of you who care about systemtap, and
    are intending to make an incompatible kernel/module interface change,
    please run the systemtap testsuite before & after. If it regresses,
    send us a note or a patch. If practical, we'll integrate it (and add
    any backward-compatibility hacks if needed) into systemtap.


    - FChE
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    On Wed, Jul 23, 2008 at 12:41:37PM -0400, Frank Ch. Eigler wrote:
    >...
    > In the interim (before we come up with a way of moving more
    > kernel-coupled systemtap code into kernel.org/git), would y'all
    > consider an arrangement? Those of you who care about systemtap, and
    > are intending to make an incompatible kernel/module interface change,
    > please run the systemtap testsuite before & after. If it regresses,
    > send us a note or a patch. If practical, we'll integrate it (and add
    > any backward-compatibility hacks if needed) into systemtap.


    The number of incompatible kernel/module interface changes per kernel is
    most likely some medium three digit number.

    What you have in mind is therefore not really feasible.

    But we have several levels of kernels that incorporate future stuff,
    from -rc over -next to -mm, and you could implement automated runs
    of the systemtap testsuite against the latest ones.

    > - FChE


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    Hi -

    On Wed, Jul 23, 2008 at 07:54:05PM +0300, Adrian Bunk wrote:
    > On Wed, Jul 23, 2008 at 12:41:37PM -0400, Frank Ch. Eigler wrote:
    > >...
    > > In the interim (before we come up with a way of moving more
    > > kernel-coupled systemtap code into kernel.org/git), would y'all
    > > consider an arrangement? Those of you who care about systemtap, and
    > > are intending to make an incompatible kernel/module interface change,
    > > please run the systemtap testsuite before & after. [...]


    > The number of incompatible kernel/module interface changes per
    > kernel is most likely some medium three digit number. What you have
    > in mind is therefore not really feasible.


    Do you think so, even if the historical pattern continues that only a
    small fraction of those changes actually impact systemtap?


    > But we have several levels of kernels that incorporate future stuff,
    > from -rc over -next to -mm, and you could implement automated runs
    > of the systemtap testsuite against the latest ones.


    We do some of that already and should do more.


    - FChE
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    On Wed, Jul 23, 2008 at 01:34:38PM -0400, Frank Ch. Eigler wrote:
    > Hi -
    >
    > On Wed, Jul 23, 2008 at 07:54:05PM +0300, Adrian Bunk wrote:
    > > On Wed, Jul 23, 2008 at 12:41:37PM -0400, Frank Ch. Eigler wrote:
    > > >...
    > > > In the interim (before we come up with a way of moving more
    > > > kernel-coupled systemtap code into kernel.org/git), would y'all
    > > > consider an arrangement? Those of you who care about systemtap, and
    > > > are intending to make an incompatible kernel/module interface change,
    > > > please run the systemtap testsuite before & after. [...]

    >
    > > The number of incompatible kernel/module interface changes per
    > > kernel is most likely some medium three digit number. What you have
    > > in mind is therefore not really feasible.

    >
    > Do you think so, even if the historical pattern continues that only a
    > small fraction of those changes actually impact systemtap?


    But which are these?

    All commits that either remove EXPORT_SYMBOL's or touch include/ are
    candidates would have to be checked, and that's a four digit number
    of commits per kernel release.

    What is not feasible is to check each of thesse commits.

    > > But we have several levels of kernels that incorporate future stuff,
    > > from -rc over -next to -mm, and you could implement automated runs
    > > of the systemtap testsuite against the latest ones.

    >
    > We do some of that already and should do more.
    >
    > - FChE


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    Hi,

    Peter Zijlstra wrote:
    > On Wed, 2008-07-23 at 11:04 -0400, Frank Ch. Eigler wrote:
    >> Hi -
    >>
    >> I wrote:
    >>
    >>>> [...] One significant requirement for us is to keep working with
    >>>> older kernels. [...]

    >> Maybe it's worth elaborating on why the need for backward
    >> compatibility is different for systemtap than for typical kernel-side
    >> code.
    >>
    >> The bulk of systemtap is a user-space program, and it does very
    >> user-spacey things like parsing dwarf and invoking compilers, running
    >> network servers. Soon it will include user-space libraries. It is so
    >> different from the stuff normally found there that no one has AFAIK
    >> seriously proposed that the entire software be made part of the kernel
    >> git tree. So it is an ordinary separate user-space package, built by
    >> users and distributors.
    >>
    >> It does happen to *generate* kernel modules. The way that such a
    >> module must interface with any particular kernel is naturally subject
    >> to the whims & desires of the kernel du jour. This is why we have a
    >> mass of mechanism to try to automatically speak to each kernel version
    >> as appropriate.
    >>
    >> It is desirable to minimize this mass for obvious reasons. When a new
    >> upstream kernel comes out with a tasty new feature -- or a less tasty
    >> API rewrite -- we need to extend systemtap to support that too. We
    >> cannot easily take old support away, because then the same user-space
    >> code base would no longer run against actually installed kernels.
    >>
    >> To draw an analogy, systemtap is somewhat like low-level userspace
    >> code like glibc or syslogd or udevd. I hope no one would seriously
    >> propose casually committing code to those packages that would make
    >> them unusable on prior kernel versions. Accepting such a patch would
    >> require their maintainers to fork outright every time a kernel change
    >> occurs.
    >>
    >> Things are good however if the low-level userspace changes are
    >> backward-compatible, so that the new kernel facility is used when
    >> present, but the software does not regress if it is not. I believe
    >> this is what we need to aim for, even though it puts the bulk of the
    >> burden on systemtap (or glibc, or ...).
    >>
    >> I hope this fills in some of the gaps in the background.

    >
    > Why does a new version of stap have to work on ancient kernels?
    >
    > A new gnome version requires a new gtk version, a new kde version
    > requires a new qt etc.. so why does a new stap not require a new kernel?
    >
    > Why isn't only supporting the last few kernels, say for example as far
    > back as there are -stable series at the moment of release, good enough?
    >
    > People who insist on running stale kernels are usually the same people
    > who run stale userspace - we call those enterprise people - so why can't
    > they run matching stale version of the kernel and stap?


    I agree with you. currently, systemtap is increasingly evolving
    on single source tree. But it is obvious that this developing style
    can't catch up the upstream development.
    I'd like to suggest that we might better branch the tree --
    one is stable tree for old kernel, another aims to merge into upstream.

    Thank you,

    --
    Masami Hiramatsu

    Software Engineer
    Hitachi Computer Products (America) Inc.
    Software Solutions Division

    e-mail: mhiramat@redhat.com

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs

    Hi Frank,

    Frank Ch. Eigler wrote:
    > Arjan van de Ven writes:

    [...]
    >> (and when it's seen it gets a rather luke warm reception, but that's
    >> a different story).

    >
    > I hope the backward compatibility issue, as it stands today, helps
    > explain the reasons for the current deal with kprobes.


    I understood that the current deal with kprobes is also for integrating
    user probe logic and kernel probe logic.
    Obviously, it is hard uprobe to provide same symbol_name interface,
    because it requires to access(and analyze) userspace symbol
    information from kernel.

    > In the interim (before we come up with a way of moving more
    > kernel-coupled systemtap code into kernel.org/git), would y'all
    > consider an arrangement? Those of you who care about systemtap, and
    > are intending to make an incompatible kernel/module interface change,
    > please run the systemtap testsuite before & after. If it regresses,
    > send us a note or a patch. If practical, we'll integrate it (and add
    > any backward-compatibility hacks if needed) into systemtap.


    Hmm, I think it's very costly way for both of kernel developers and
    systemtap developers.
    From the long term of viewpoint, I think it's better (less costly)
    to merge systemtap runtime/tapset into upstream kernel and maintain
    it. Then, we can stabilize its API by ourselves on upstream.
    Since it reduces the catchup/maintenance cost and it enables users
    to use stap on upstream kernel, I think it is benefit for both.

    Thank you,

    --
    Masami Hiramatsu

    Software Engineer
    Hitachi Computer Products (America) Inc.
    Software Solutions Division

    e-mail: mhiramat@redhat.com

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2