It's a bad idea to claim to support /dev/urandom but rely on HW RNG
because starting up Cassandra, for example, takes ages.

Drop it until we have a cryptographically secure PRNG in OSv that can be
used to implement /dev/urandom properly.

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

Convert file::f_ops/fileops to file's vtable.

Reviewed-by: Pekka Enberg <penberg@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>

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

Everyone is now overriding file's virtual functions; we can make them
pure virtual and remove fileops completely.

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

Unused.

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

Everyone switched to the nifty variadic type.

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

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

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

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

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

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

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

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

Useful for C -> C++ conversions.

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

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

Not everyone wants it.

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

Derived file objects will be initialized by the class constructor, no need
for fo_init().

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

Once file::~file() is called, virtual functions no longer dispatch to the
derived type (which has since been destroyed) but to the base type, which
is uninteresting.

Move the call to close() from the destructor to fdrop().

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

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

This is a temporary measure before the module definition is moved to
the mgmt repo.

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

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: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@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>

They are temporary files for vim and should be ignored.

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

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: Asias He <asias@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Besides simplifying mmu::map_file interface, let's make it more similar
to mmu::map_anon.

Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This will allow the users to populate /usr with simples binaries like haproxy
and their config at runtime.
It's intented to be combined with the loader ability to run multiple binaries
in a sequential way.
For example -e '/tools/cpiod.so; /usr/haproxy.so -f /usr/haproxy.conf'

Signed-off-by: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

This pave the way for the creation of bare images that the user can populate
using cpiod when he need it.

Signed-off-by: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

A ';' at the end of a parameter mark the end of a program's arguments list.

The goal of this patch is to be able to split mkfs.so in to parts mkfs.so and
cpiod.so.

The patch uses a full spirit parser to escape "" and split commands around ';'.

Signed-off-by: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

We had at least one report for a system in which the __mm_setcsr function
we were using is not found. Since this is heavily arch specific anyway,
we should just use inline assembly to do so.

Generated code verified to be the same:

  33c6e7:       c7 45 e0 80 1f 00 00    movl   $0x1f80,-0x20(%rbp)
  33c6ee:       0f ae 55 e0             ldmxcsr -0x20(%rbp)

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

The main purpose is to exercise the new parameter checks added to
mmap to handle wrong combination of parameters.
Let's intentionally force errors and catch them with the respective errno codes.

Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

(flags & MAP_ANONYMOUS) must be instead of (fd == -1) to determine
the mapping type as the latter one is a valid argument to file mappings.
Tests related to files were added into mmap_validate_file.

Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

Rename mmap_validate_flags to mmap_validate as it's not only related to
flags now.  Add new tests to check bad paramater values.

Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>

storage/runtime arguments for tracepoint can be inferred from
assign() function signature instead of specified explicitly
by storage_args/runtime_args. This makes boilerplate code smaller.

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

The default is to dispatch directly to the corresponding member of f_ops,
but that can be overridden.

The fo_*() functions are redirected to dispatch via the virtual functions.

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

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

Make sure ZFS intention log is flushed to disk by unmounting rootfs at
poweroff.

Fixes #108.

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

Make sure the new root vnode is not evicted in vflush() and that we
don't keep reference to the old root dentry in ->m_covered.

Fixes negative dentry count when pivoted root is unmounted.

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

Add sys_umount2() and implement support for MNT_FORCE that will be used
to force rootfs unmount at poweroff.

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

This is a temporary fix. I really feel we need failure detection based
on exit code.

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

Add error scanning to test.py based on known patterns in stdout and
stderr and stop test execution on error to make broken test cases stand
out.

Example output looks as follows:

  PASS: link returns ENOENT if source path does not exists
  PASS: create a file
  PASS: close the file
  PASS: create a hard link
  PASS: link returns EEXIST if destination path exists
  PASS: read content from another link
  PASS: stat the file
  PASS: hard link count is increased
  PASS: stat the hard link
  PASS: stat device IDs match
  PASS: stat inode numbers match
  PASS: remove the hard link
  PASS: stat the file
  FAIL: hard link count is decreased
  PASS: remove the file
  SUMMARY: 15 tests, 1 failures
  Powering off.

  Test '/tests/tst-fs-link.so' FAILED
  make: *** [check] Error 1

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