[ktap] Re: POC for ktap ffi support

  • From: Jovi Zhangwei <jovi.zhangwei@xxxxxxxxx>
  • To: Qingping Hou <dave2008713@xxxxxxxxx>
  • Date: Sun, 3 Nov 2013 16:49:01 +0800

On Sat, Nov 2, 2013 at 2:37 PM, Qingping Hou <dave2008713@xxxxxxxxx> wrote:
> Hi all,
>
> We made a POC for ktap ffi support. This feature makes it possible to
> call into Kernel C function directly from inside ktap script.
>
> A brief overview of current design:
>
> * user define needed C symbols in ktap script (functions, structs, etc)
> * C symbols get compiled into chunk and passed into ktap vm
> * ktap vm generates ktap_ctype according to symbol information from
> chunks and populates the global "C" table
> * when ktap script calls "C.foo()", ktap vm detects that it's a FFI
> function, and does following:
>   - sets up the hardware stack
>   - calls into the C function
>   - put back return value to ktap stack
>
> Implementation of C function call is under interpreter/ffi/ffi_call.c,
> including argument check, type conversion, stack setup and return value
> handling.
>
> Noted that in this POC, C symbol definitions are not compiled into ktap
> chunk yet. Because we are still working on a C header parser. Currently,
> we work around it by defining C symbols in ktap table and populate
> global "C" table in runtime. That way we can focus on the FFI call
> implementaion. This will be fixed in the third milestone.
>
>
> Branch:
> https://github.com/unihorn/ktap/tree/ffi-cp1
>
> Support:
> - x86_64 machine
> - int, long, longlong and void type
> - kernel functions that are defined in C table in script
> - implicit type conversion between ctypes and ktap types
>
> Test:
> New test script is under test/ffi/
> ```
> # ./ktap test/ffi/cdef.kp
> ```
>
> Plan:
> https://github.com/ktap/ktap/wiki/FFI-Support
>
>
> Please feel free to point out any problem in the design so we fix it as
> soon as possible :)
>
> Regards,
> Yicheng & Qingping
>
Great work!
Now I have big confident ktap will became more attractive when after
merge ffi feature contributed by your guys. :)

Quick glanced, the code looks clean and easy to understand.
I just have some comments, I think it's better to review it though mail
not in github, as I found we can easily lost review comments in github
(like branch delete and commit rebase), so would you please post
the patch into ktap@xxxxxxxxxxxxx?

Don't worry the size of patch, it's better to split the patch into patch
serials, but it's fine if you think it's hard to do that in this phase.

Thank you.

Jovi.

Other related posts: