lkml.org 
[lkml]   [2014]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 15/28] ktap: add built-in functions and library (runtime/lib_*.c)
    From
    On Mon, Mar 31, 2014 at 9:13 PM, Andi Kleen <andi@firstfloor.org> wrote:
    > On Mon, Mar 31, 2014 at 10:01:04AM +0800, Jovi Zhangwei wrote:
    >> On Sun, Mar 30, 2014 at 8:58 AM, Andi Kleen <andi@firstfloor.org> wrote:
    >> >> Maybe in future, after ktap support "include" or "require" to
    >> >> import user defined library in userspace.
    >> >
    >> > Can't you just have some hardcoded standard script for now that is
    >> > always appeneded and provides these functions?
    >> >
    >> Maybe it's fine to hardcoded just for now.
    >>
    >> Since we are agreed on review userspace part in another schedule,
    >> so I will remove this ansi library from kernel part in next version.
    >>
    >> Thanks for this suggestion.
    >
    > Please do the following for the next version:
    >
    > - Don't repost with all the TODOs regarding changing other
    > kernel parts. Just fix them.
    >
    Sure.

    > - As others pointed out elsewhere it's too big and full featured right
    > now. Please find ways to define a useful "core ktap" for now with less
    > features. This could be dropping library parts or dropping some of the
    > probe types or some parts of the language. These can then be later phased
    > in over time. For the library it may make sense to add some module
    > interface and keep parts of it external for now?
    >
    I will remove some library and raw tracing interface(designed for benchmark)

    > - Please run as much test content as you have with all the kernel debug
    > options to automatically find bugs. I would at least two runs one with
    > lockdep/lock debugging/preempt debugging/slab/page debugging etc.
    > and another with kmemleak (that is exclusive with some other options)
    > Some of these checks may have false positives, but the messages
    > should be all analyzed at least, and false positives commented.
    >
    ktap runs fine in lockdep/lock debugging/preempt debugging, but not
    try to run in slab/page debugging and kmemleak. I will do that.

    > - Do similar with the static compile time checks: checkpatch,
    > sparse, coccinelle. There will be likely a lot more false positives
    > here, so it may not be feasible to check all, but should at least
    > eyeball the output to see if there are some obvious problems.
    > For sparse it would be also good to annotate the user ioctl
    > parts with __user and carefully look at the warnings there,
    > as that is a common problem area.
    >
    Sure.

    I will send out new version once we make agreement on ktap
    upstream which discussing in another thread.

    Thanks for these comments.

    Jovi


    \
     
     \ /
      Last update: 2014-04-02 04:21    [W:3.784 / U:0.828 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site