lkml.org 
[lkml]   [2014]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 15/28] ktap: add built-in functions and library (runtime/lib_*.c)
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.

- 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?

- 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.

- 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.

-Andi


\
 
 \ /
  Last update: 2014-03-31 16:21    [W:0.092 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site