Skip to content
Snippets Groups Projects
Select Git revision
  • simonci
  • vanillaCI
  • ibr/cpu-event-worker-leanstore-integration
  • ibr/cpu-event-worker
  • revert-dbd4f905
  • ibr/event-sched
  • job-queue
  • debug-shed-with-sclicing-and-multiple-cores
  • pr/sched-rr
  • ibr/sched-rr
  • dietrich/rwlock
  • dietrich/tcb-shrink
  • dietrich/memory-compression
  • master default protected
  • job-queue-load-balance
  • vldb24-vision
  • ipv6
  • riscv64
  • stable/v0.19
  • static-elf
  • v0.57.0
  • v0.56.0
  • v0.55.0
  • v0.54.0
  • v0.53.0
  • v0.52.0
  • v0.51.0
  • v0.24
  • v0.23
  • v0.22
  • v0.21
  • v0.20
  • v0.19
  • v0.18
  • v0.17
  • v0.16
  • v0.15
  • v0.15-rc3
  • v0.15-rc1
  • v0.14
40 results
Search by author
  • Any Author
  • Christian Dietrich Christian Dietrich dietrich
  • Niklas Gollenstede Niklas Gollenstede gollenst
  • Sebastian Kosak kosak
  • Simon-Nassim Kanoun kanoun
  • Sören Tempel Sören Tempel tempel
5 authors
  1. Dec 04, 2013
    • Tomasz Grabiec's avatar
      modules: Use OSV_BASE variable in manifest for mgmt · ef3b7ffe
      Tomasz Grabiec authored 
      
This is a temporary measure before the module definition is moved to
the mgmt repo.

Signed-off-by: default avatarTomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      ef3b7ffe
    • Tomasz Grabiec's avatar
      modules: Add support for resolving variables in manifest rules · e4728e1e
      Tomasz Grabiec authored 
      
Manifests should contain paths in the same file system in which the
image is built. Currently manifests assumed that the module will be
downloaded/copied into build/*/module/ and that the CWD is inside
build/*. This is not always the case now that we have "direct-dir"
module type, which is is not copied.

Example use:

    /usr/x:${MODULE_DIR}/x

This patch adds MODULE_DIR variable, which is replaced with the path
to the module in local file system. Depending on the module type this
can be either direct path or a path inside build/*/module/.

Signed-off-by: default avatarTomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      e4728e1e
    • Tomasz Grabiec's avatar
      modules: Add support for run configurations · ccc51b6f
      Tomasz Grabiec authored 
      
    == 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: default avatarTomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      ccc51b6f
    • Asias He's avatar
      Add .swp files to gitignore · c794324c
      Asias He authored 
      
They are temporary files for vim and should be ignored.

Signed-off-by: default avatarAsias He <asias@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      c794324c
    • Asias He's avatar
      build.mk: Rename usr.raw to bare.raw · 8197a553
      Asias He authored 
      
We have an intermediate bare.img now. Rename usr.raw to bare.raw to make the
naming more consistent: bare.raw -> bare.img -> usr.img.

Signed-off-by: default avatarAsias He <asias@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      8197a553
  3. Dec 03, 2013