When we use wait_until(), e.g.,

        wait_until([&] { return *x == 0; })

We used (in a bunch of places in the code, including condvar) the
following "obvious" idiom to wake it up:

        *x = 0;
        t->wake();

This does the right thing in *almost* all situations. But there's still
one rare (but very possible) scenario where this is wrong. The problem is
that the first line (*x = 0) may already cause the wait_until to return.
This can happen when wait_until didn't yet check the condition, or if it
was sleeping and by rare coincidence, got woken up by a spurious interrupt
at the same time we did *x = 0. Now, consider the case that the waiting
thread decides to exit after the wait_until... So the "*x = 0" causes the
thread to exit, and when we want to do "t->wake()" the thread no longer
exists, and the statement crashes.

This patch adds two new thread methods: t->ref() increments a counter
preventing a thread's destruction, until a matching t->unref().
With these methods, the correct way to wake the above wait_until() is:

        t->ref();
        *x = 0;
        t->wake();
        t->unref();

This patch also adds a one-line shortcut to the above 4 lines, with syntax
mirroring that of wait_until:

        t->wake_with([&] { *x = 0; });

The ref()/unref() methods are marked private, to encourage the use of
wake_with(), and also to allow wake_with() in the future to be optimized
to avoid calling ref()/unref() when not needed. For example, when the thread
is on the same CPU as the current thread, merely disabling preemption (a
very fast operation) prevents the thread from running - and exiting - and
ref()/unref() are not necessary.

Unfortunately, while this patch solves one bug, it does not solve two
additional bugs that existed before, and continue to exist after this
patch:

1. When a thread completes (see thread::complete()) it wakes a thread
   waiting on join() (if there is one) and this join() deletes the thread
   and its stack. The problem is that if the timing is right (or wrong ;-)),
   the joiner thread may delete the stack while complete() is still
   running on this stack, and can cause a crash.

2. If join() races with the thread's completion, it is possible that
   the thread thinks nobody is waiting for it so notifies nobody, but
   at the same time join() starts to wait, and will never be woken up.

Added two "FIXME" about these remaining bugs.

lseek() crashes when used on pipes, sockets, and now also fd 0, 1 or 2
(the console), because they don't have an underlying vnode. No reason
to assert() in this case, should just return ESPIPE (like Linux does
for pipes, sockets and ttys).

Similarly, fsync, readdir and friends, fchdir and fstatfs shouldn't
crash if given a fd without a vnode, and rather should return the
expected error.

We had a bug where a read() on the console (fd 0) would block writes to
the console (fd 1 or 2). This was most noticable when background threads
in the CLI tried to write output, and were blocked until the next keypress
because the blocking read() would lock the writes out.

The bug happens because we opened the console using open("/dev/console")
and dup()'ed the resulting fd, but this results, in the current code, in
every read and write to these file descriptors to pass through vfs_read()/
vfs_write(), which lock a single vnode lock for all three file descriptors -
leading to write on fd 1 blocking while read is ongoing on fd 0.

This patch doesn't fix this vnode lock issue, which remains - and should
be fixed when the devfs or vfs layers are rewritten. Instead, this patch
adds a *second API* for opening a console which doesn't go through the
vnode or devfs layers:

A new console::open() function returns a file descriptor which implements
the correct file operations, and is not associated with any vnode.

The new implementation works well with write() while read() is ongoing.

Note that poll() support was missing from the old implementation (it
seems it can't be done with the vnode abstraction?) and is still missing
in the new implementation, although now shouldn't be hard to add
(need to implement the poll fileops, and to use poll_wake() in the
line-discipline function console_poll).

tab completion relies on a global 'ls' object, re-add it.

Broken by 4bfe157b.

Sorry, missing unsupported_poll broke compilation after the previous patch

This is an epoll_*() implementation which calls poll() to do the real work.
This is of course a terrible implementation, which makes epoll() less
efficient, instead of more efficient, then poll(). However, it allows me
to progress with running Jetty in parallel with perfecting epoll.

It's not clear if our DNS resolver works or not - need to test and fix
if needed.

Trivially implement mtx_assert(). This would catch the "ifconfig" bug
fixed in the previous patch - where ifconfig called sofree() without
the accept lock.

ifconfig used to call sofree(), which assumed accept_mtx was taken, which
wasn't true, resulting in either an assertion failure (if we implement
assert_mtx - see next patch) or a mutex corruption (if assert_mtx does
nothing).

Instead, we should call soclose(). This wasn't very hard to figure out,
given the comment in socreate() saying "The socket should be closed with
soclose()." :-)

This patch turns on the flag which switches all our code to use the
lock-free mutex instead of the spinlock-based mutex.

It's time we start using the lock-free mutex, which is stable enough by
now - but please let me know if you do experience any performance problem,
or bugs, related to the new mutex.

If you need to disable the new mutex temporarily and return to the old,
just change the "#define LOCKFREE_MUTEX" in osv/mutex.h to #undef.

Returning a void does nothing, and just confusing.

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

This single Java source file is a full-fledged HTTP 0.9 server.
I wanted to add it to expose the console lock bug (fixed in a separate
patch), and to verify that bind() works correctly (it does).

But additionally, this tiny HTTP server (about 6KB of compressed bytecode)
can be very useful for our CLI - it can be run in the background and let
you view files in the OSV system in your browser, even while another
program is running.

To run Shrew from the CLI, just run

	java com.cloudius.cli.util.Shrew

Which runs the HTTP server in the background (in a separate thread),
letting the user continue to use the CLI. If you add an argument "fg" to
this command, it runs the server in the current thread, never returning.

Currently, the HTTP server is written to browse OSV's root directory
hierarchy: accessing http://192.168.122.100:8080/ from the host shows
you the OSV guest's root directory, and you can decend into more
directories and download individual files.

Instead of defining a command object in one file and registering it in
another, do everything in one place.

- per-cpu variables
- per-cpu kvmclock
- tracepoint probe functions
- tracepoint Java API
- 'perf stat' cli command

Usage:

  perf list (lists all tracepoints)
  perf stat tp... (counts tracepoints)

Example:

[/]$ perf stat mutex_lock ctxsw=sched_switch mutex_unlock wake=sched_wake
  mutex_lock   ctxsw  mutex_unlock    wake
          40       3          1909       2
        2075     147           190      82
         193     138           193      78
         146     139           146      92
         317     179           317      78
         146     139           146      78
         146     139           186      78
         205     139           165      78
         146     139           146      78
         146     139           146      78
         146     139           146      80
         193     143           193      81
         151     147           151      78
         146     139           146      78
         146     139           146      78
         146     139           146      78
         159     139           159      78
         149     139           149      78
         146     139           146      78
         164     139           164      78
         146     139           176      78
         176     139           146      78
         149     139           149      78
         146     139           146      78
         146     139           146      78
  mutex_lock   ctxsw  mutex_unlock    wake
         146     139           146      79
         715     147           715      80
         188     139           204      78

Don't actually implement it either yet, but at least don't abort.

We already get these from our API version of <sys/mount.h>

We don't use this header for user APIs and they conflict with the ones
from sys/mounts.h

java.lang.Math will override JavaScript's Math object.

Exposes tracepoints and counters

Add a facility to run functions when a tracepoint is hit.  This is independent
of logging; you can add a probe function with logging disabled or enabled.

The kvmclock ABI requires it to calculate system time using values for the cpu
it is running on.

Do this by:
  - changing the system time structure to be per-cpu
  - adding a cpu notifier so that per-cpu MSRs are initialized for each cpu
  - hacking around initialization order issues

cpu notifiers are called whenever a cpu is brought up (and one day, down), so
that drivers that manage the cpu (for example, kvmclock) can initialize
themselves.

The callback is called on the cpu that is being brought up.

Per-cpu variables can be used from contexts where preemption is disabled
(such as interrupts) or when migration is impossible (pinned threads) for
managing data that is replicated for each cpu.

The API is a smart pointer to a variable which resolves to the object's
location on the current cpu.

Define:

   #include <osv/percpu.hh>

   PERCPU(int, my_counter);
   PERCPU(foo, my_foo);

Use:

   ++*my_counter;
   my_foo->member = 7;