Now that backtrace() doesn't use libunwind, we can remove it.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

    == Description of the problem ==

Currently modules can only specify files which need to be
copied. There is a need for a module to also declare ways it can be
run, so that we can automatically prepare a runnable image. It
should be easy to switch between run configurations.

Currently it is enough for image configuration to happen at the
time of image make process. In future this should be allowed
on the already built image.

We also need to be able to combine multiple modules in one
image. For example in addition to the main application one might want
to start various services like CLI, management API server, etc.

Java apps should be able to specify JVM arguments, which must be
passed to the JVM upon its creation, as well as regular run-java
arguments (classpath, main classes, main arguments, etc.)

    == Solution ==

This is not intended to be a permanent solution. The aim is to solve
immediate need to have a fully modularized build in a scalable way.

Every module has a new kind of file in its root directory which
holds its configuration. The file is named 'module.py' and is
a python script which uses osv's api for declaring run configurations.

Using python as config language has several advantages:
 - more expresiveness, unlike json it allows for expression reuse
 - it's easier to extend the config language
 - we don't need as much parsing, gluing, error checking, error
   reporting code because we have it already

There are currently two kinds of applications which can be declared:

   run(cmdline)  <- basic .so application
   run_java(jvm_args=[], classpath=[], args=[])  <- java applications

Run configurations can be declared as simple module attributes
which can be referenced from the image configuration file.

Image configuration

There is a new configuration file kind, which defines which modules
and which run configurations should be included in the image. Files
are located using path: ${OSV_BASE}/images/$(image-name).py

Syntax:

  require(module) <-- declares that module should be included in the image
  		      and returns an object which allows to access module's
		      attributes.

  run = []  <-- list of run configurations

Example:

  _mgmt = require('mgmt')
  run = [ _mgmt.shell ]

To use a particular image configuration run make like this:

  make image=fancy-tomcat

The default configuration is named 'default'.

This patch extracts mgmt into a module, which is embedded under
${OSV_BASE}/modules/mgmt

The purpose of ${OSV_BASE}/config.json has been changed. It does not
list modules which should be included anymore, image config file does
that. It's a module look-up configuration which tells the build where
to look for modules.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This allows to use these variables inside build.mk regardless of CWD
and is more clear than a cascade of ".."s

This change also unifies $(submake) and $(modulemk) generation
to reduce duplication.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

The idea of the patch is basically described in prevoius post:

https://groups.google.com/d/msg/osv-dev/RL2S3AL9TNE/l4XZJo3-lI0J

Whis this patch, you will be able to install OSv apps into disk image on
"make all" stage.

These apps does not require to exist in OSv repository, you can install
apps which is on any git repository or svn repository, or on local
directory.

You'll need to write a config file to add apps, format of the file is
JSON.

Here's a sample of the file:
{
   "modules":[
      {
	 "name":"osv-mruby",
         "type":"git",
         "path":"https://github.com/syuu1228/osv-mruby.git",
         "branch":"master"
      }
   ]
}

If you add "module" on config file, make all calls script/module.py.

This scripts perform "git clone" to fetch repository to $(out)/module,
and invoke "make module" on each module.

"make module" should outputs bootfs.manifest/usr.manifest on module
directory, the script merge bootfs.manifest.skel/usr.manifest.skel and
module local manifests to single file
$(out)/bootfs.manifest/$(out)/usr.manifest.

Here's app Makefile example:

  https://github.com/syuu1228/osv-mruby/blob/master/Makefile



It have "module" target, and the target builds all binaries and
generates *.manifest.

Signed-off-by: Takuya ASADA <syuu@dokukino.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Make use of the python nbd client.

Signed-off-by: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

Add a 'make check' target that runs whitelisted tests under OSv.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Building with ant requires no changes in the build scripts
when new classes are added. It is a standrd tool to build
java programs.

Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

'make mgmt=0' will skip building the management code.  It is up to the
developer to ensure that a previously built tree is in place.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

Before:

  [penberg@localhost osv]$ time make clean
    CLEAN
    GRADLE CLEAN

  real	0m4.026s
  user	0m8.732s
  sys	0m0.212s

After:

  [penberg@localhost osv]$ time make clean
    CLEAN
    GRADLE CLEAN

  real	0m1.658s
  user	0m0.962s
  sys	0m0.162s

Signeg-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Drop implicit makefile rules; this prevents make from looking for fortran
source files, etc.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

Speeds up mgmt null build considerably

The "cscope" make target piped a list of files into "cscope -bq", but
this command doesn't read its input. The command should be "cscope -bq -i-"
which reads the list of files from stdin.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>

This will generate cscope index for the source files.

Signed-off-by: Liu Yuan <namei.unix@gmail.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Currently, OSv's "make" builds both the kernel, using a normal Makefile,
and the sample management framework, using the "Gradle" tool.

We carefully hid Gradle's progress under one output line "GRADLE", but
this leads to the "make" process hanging for a long time - up to several
minutes, and all the puzzled user sees is the line "GRADLE". Users who
didn't go for coffee will likely kill the build at this point ;-) Even
worse, when Gradle fails, or just hangs (e.g., a bad or slow network
connection), the user won't even know why.

So let's just run Gradle normally, and let the user see its full output.
This output is rather pretty and organized, so no real reason to hide it.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>

Each of the "tags" and "TAGS" make targets was done in a different way,
causing each to have a different problem:

 1. "tags" (ctags) used the "-L" option which turns out is nonportable
    (only available in Exuberant Ctags).
 2. "TAGS" (etags) ran the etags command separately for each source file,
    slowing it down.

The best of both worlds is to use xargs to have ctags/etags operate on
multiple files in each run using xargs. Because we cannot be sure xargs
will run ctags/etags only once, we must delete the file first and use
 the "-a" (append) option.

Also, this patch reduces code duplication - there is now one rule for
both "tags" and "TAGS" targets that uses the correct tool (ctags or etags,
respectively).

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>

Added comments to explain the target tags and TAGS,
also ignore the output file of ctags.

Signed-off-by: Yang Bai <hamo.by@gmail.com>

add TAGS target to Makefile to support etags.

Signed-off-by: Yang Bai <hamo.by@gmail.com>

Running "ctags -R" takes a long time because of git submodules:

  [penberg@localhost osv]$ time ctags -R

  real	0m35.076s
  user	0m18.770s
  sys	0m3.929s

Add a "make tags" target that's much faster to run:

  [penberg@localhost osv]$ time make tags
  find . -name "*.cc" -o -name "*.hh" -o -name "*.h" -o -name "*.c" | ctags -L -

  real	0m0.980s
  user	0m1.033s
  sys	0m0.158s

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Add a "qcow2" target to Makefile that uses "qemu-img convert" to build a
smaller qcow2 image out of the OSv raw image.

Eclipse recognizes .mk as a makefile, make it easier for new users to
use eclipse.

We need to ifdef out more unused code to not make gcc complain.

Added build ("make") framework for compiling Java code we want to run in
OSv (in/with the Java payload), as well as JNI, i.e., OSv-specific C code
we want to run from the above Java code.

The Java source files in java/src/ are now all compiled during build
(see java/build.xml for the Ant file doing this compilation) and the
result is one JAR, build/$mode/java/cloudius.jar (/cloudius.jar in bootfs).
We can easily change build.xml to create more than one if we want.

As an example of JNI, I used the not-working-yet balloon feature.
java/src/com/cloudius/balloon/Balloon.java is the class
com.cloudius.balloon.Balloon which is supposed to have one "native"
(implemented in C) function giveup(). This function's implementation is
in java/jni/balloon.c. We get this file to compile to balloon.so (put
in /usr/lib/jni in the bootfs) by adding java/jni/balloon.so to the
"jni" list in build.mak.

If you don't know how write the ugly function signature as seen in
java/jni/balloon.c, you can run "javah com.cloudius.balloon.Balloon"
to build the empty functions needed for implementing the native functions
defined in the above class.

If a target fails to build, it is probably corrupted.  Delete it.

Fixes misbuild after a second make with an incorrect bootfs.manifest.

Not completely silent unfortunately.

One test so far: java.lang.System.nanoTime()

We're only about 500% slower than native.

-MD accepts no argument, and luckily the argument we supplied evaluated to
nothing.  Remove it.

the -MP switch allows make to ignore deleted files.

this gives us better dependency tracking.