[sheepdog] [PATCH v4 2/2] tests: add a DynamoRIO client for testing the jounaling mechanism

[Hitoshi Mitake]

At Mon, 8 Jul 2013 17:05:22 +0800,
Kai Zhang wrote:
> 
> 
> On Jul 8, 2013, at 4:22 PM, Hitoshi Mitake <mitake.hitoshi at gmail.com> wrote:
> 
> > At Mon, 8 Jul 2013 16:14:41 +0800,
> > Kai Zhang wrote:
> >> 
> >> 
> >> On Jul 5, 2013, at 11:06 AM, Hitoshi Mitake <mitake.hitoshi at lab.ntt.co.jp> wrote:
> >> 
> >>> This patch adds a DynamoRIO (often called DR) client for testing the
> >>> jounaling mechanism. Because of its nature, the recoverying path is
> >>> the most important and hard to test part of the journaling
> >>> mechanism. They need to be tested well.
> >>> 
> >>> But testing targetted recovery paths with traditional tests/ stuff is
> >>> hard because:
> >>> 1. killing sheeps with kill commands doesn't take into account the
> >>>  internal state
> >>> 2. inserting exit()s into sheep manually is a painful work
> >>> 
> >>> So this patch implements a fault injection mechanism with DR. DR
> >>> provides rich functionalities of transparent dynamic
> >>> instrumentation. One of the functionalities makes inserting function
> >>> calls before and after system calls possible. With this mechanism, the
> >>> fault injection mechanism lets sheep exit at suitable timings for
> >>> testing recovery paths of the journaling.
> >>> 
> >>> How to use:
> >>> 0. preparation
> >>>  $ cd
> >>>  $ svn checkout http://dynamorio.googlecode.com/svn/trunk/ dynamorio
> >>>  $ cd dynamorio
> >>>  $ mkdir build
> >>>  $ cd build
> >>>  $ cmake ..
> >>>  $ make
> >>> 
> >>> (This patch assumes the source code of DR is store in $HOME/dynamorio,
> >>> and the build is done in $HOME/dynamorio/build)
> >>> 
> >> 
> >> Is it possible to remove this assumption?
> > 
> > Currently, no, I think.
> > 
> 
> At least, I think we should depend on an environment variable like "DYNAMORIO_HOME"
> and check it before we use it, both in shell scripts and
> CMakeList.txt

OK, this would be a good idea. I'll support it in v6 later.

> 
> BTW: my cmake cannot find DynamoRIOConfig.cmake and dynamorio-config.cmake if I didn't call sudo make install 
> in $HOME/dynamorio/build

I'm also not so familiar with DR. I don't know the above problem, sorry.

> 
> >> 
> >> 
> >>> 1. build the DR client
> >>>  $ cd tests/dynamorio/journaling/
> >>>  $ cmake .
> >>>  $ make
> >>> 
> >> 
> >> Can we use autotools for compiling?
> >> So that we can have a uniformed compile method.
> >> Is there a reason that we have to use cmake?
> > 
> > We have to use cmake because it is the way of DynamoRIO. DR is a
> > unique software, and it has no package for major distributions.
> > 
> > I think preparing a comprehensive build infrastructure for DR clients
> > are hard and too costly. Let's think about them if we have many fault
> > injectors and their maintenance cost is too high in the future.
> 
> The Makefile generated by cmake is something like:
> /usr/bin/gcc $(C_DEFINES) $(C_FLAGS) -DX86_64 -DLINUX -fno-stack-protector -o CMakeFiles/journaling.dir/journaling.c.o -c /home/kyle/dev/sheepdog/tests/dynamo\ rio/journaling/journaling.c
> which I think is not quite comprehensive. 
> And I also found an way for not using cmake at the website of DynamoRIO.
> 
> Could you explain what is the hard thing that you pointed?

Because DR provides specific functions for its extension (in this
context, the word "extension" means DR's specialized features).
e.g. If we want to use the extension called "drwrap", we have to write
following line to CMakeLists.txt:
 use_DynamoRIO_extension(journaling drwrap)

use_DynamoRIO_extension() is a cmake function and we shouldn't have
any assumptions about its internal.

As a first step, I belive that using cmake would be safe for building
DR clients.

Thanks,
Hitoshi