these tests are a bit outdated, they change the system configuration and are
not useful anymore, they were basically written to understand how stuff works.

tst-bsd-netdriver.c - was made just to figure out the network driver model of
                      freebsd.
tst-bsd-netisr.c    - same for isr layer, this tests runs over the ARP isr and
                      the system is badly wounded after it runs, it is useless today
                      and was written to figure out how netisr works.
tst-virtionet.c     - testing network interface creation using virtio,
                      today the interface is created anyway.

add simple select() implementation on top of poll(), been tested by
running netperf/iperf3 which is using select() for waiting for reads
and setting timeouts.

haven't been thourougly tested.

This patch adds pipe(). The pipes are built using the same FIFO implementation,
"af_local_buffer", as used by the existing unix-domain socketpair
implementation - while the socket-pair used two of these buffers, a pipe
uses one.

This implementation deviates from traditional POSIX pipe behavior in two
ways that we should fix in followup-patches:

1. SIGPIPE is not supported: A write to a pipe whose read end is closed
   will always return EPIPE, and not generate a SIGPIPE signal.
   Programs that rely on SIGPIPE will break, but SIGPIPE is completely out
   of fashion, and normally ignored.

2. Unix-style "atomic writes" are not obeyed. A write(), even if smaller
   than PIPE_BUF (=4096 on Linux, whose ABI we're emulating), may partially
   succeed if the pipe's buffer is nearly full. Only a write() of a single
   byte is guaranteed to be atomic.

   We hope that Java doesn't rely on multi-byte write() atomicity
   (single-byte writes are enough for waking poll, for example), and users
   of Java's "Pipe" class definitely can't (as Java is not Posix-only),
   so we hope this will not cause problems. Fixing this issue (which is easy)
   is left as a TODO in the code.

Additionally, this patch marks with a FIXME (but doesn't fix) a serious
bug in the code's iovec handling, so writev() and readv() are expected
not to work in this version of pipe() - and also on the existing socketpair.

Added a simple readdir() and readdir_r() test.
The test is successful - it turns out readdir() had no bug, and the bug
was in mkbootfs.py, but since I already wrote the test I guess might as
well add it.

Java.so used to correctly support the "-jar" option, but did not fully
allow the other "mode" of running Java: specifying a class name which is
supposed to be searched in the class path. The biggest problem was that
it only know to find class files, but not a class inside a jar in the class
path - even if the classpath was correctly set.

Unfortunately, fixing this C code was impossible, as JNI's FindClass()
simply doesn't know to look in Jars.

So this patch overhauls java.so: Java.so now only runs a fixed class,
/java/RunJava.class. This class, in turn, is the one that parses the
command line arguments, sets the class path, finds the jar or class to
run, etc.. The code is now much easier to understand, and actually works
as expected :-) It also fixes the bug we had with SpecJVM2008's "compiler.*"
benchmarks, which forced us to tweak the class path manually.

The new code supports running a class from the classpath, and also the
"-classpath" option to set the class path. Like the "java" command line
tool in Linux, this one also recognizes wildcard classpaths. For example,
to run Jetty, whose code is in a dozen jars in /jetty, one can do:

        run.py -e "java.so -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration jetty.xml"

the atomic operations in atomic.h weren't really atomic. this is
something that was missed in the netport and now fixed.

Builds on osv an Linux.

Tests context switch performance:
  - between threads co-located on the same cpu
  - between threads on different cpus
  - between threads placed by the scheduler policy

The following test currently frequently crashes - with an abort or
assertion failure.

It's a very simple test, where 10 threads do an endless yield() loop.
While yield() itself is not very important - and doesn't even implement
the promise of sched_yield(2) to move the thread to the end of the run
queue - this test failure may be the sign of a scheduler bug that needs to
be fixed.

Allows cross-platform code where the APIs aren't the same.

 1. osv::poweroff(), which can turn off a physical machine or in our case
    tell QEMU to quit.
    The implementation uses ACPI, through the ACPICA library.

 2. osv::hang(), which ceases all computation on all cores, but does not
    turn off the machine. This can be useful if we want QEMU to remain
    alive for debugging, for example.

The two functions are defined in the new <osv/power.hh> header files, and
follow the new API guidelines we discussed today: They are C++-only, and
are in the "osv" namespace.

No code changes.

The previous implementation of backtrace() required frame pointers.
This meant it could only be used in the "debug" build, but worse,
it also got confused by libstdc++ (which was built without frame pointers),
leading to incorrect stack traces, and more rarely, crashes.

This changes backtrace() to use libunwind instead, which works even
without frame pointers. To satisfy the link dependencies, libgcc_eh.a
needs to be linked *after* libunwind.a. Because we also need it linked
*before* for other reasons, we end up with libgcc_eh.a twice on the
linker's command line. The horror...

This way we make sure any headers with the same name in the Solaris porting
glue get used first.  Also make sure the jni header is available to C code
as well.

libc: include/api
boost: external/misc.bin

bsd sources now prefer bsd's sys/ to our sys/, should be reconciled somehow
later.

The musl code contains a build time generated header; generate it.

This has the strange side effect of preventing Makefiles from being remade,
which is a feature we want to use for generated code dependencies.

Until now, OSV's console defaulted to raw mode, to make the CLI
happy. The problem is that on Linux, applications expect to be
run in cooked mode, so if we ever run a simple application that
tries to read user input, it can be confused.

This patch makes OSV console default to cooked mode, and the
CLI switch to raw mode before reading an input line - and reset
to the default mode just before running the user's command.

Unfortunately, we had to resort to adding a JNI class "Stty",
since Java has no builtin support for the ioctls required for
changing the tty settings.

This is a modified version of zlib for use by ZFS.

This isn't actually a BSD native API as FreeBSD uses a per-cpu variable
to store cpuids, but rather a replacement we can use.

While trying to run the "compiler.compiler" benchmark from SPECjvm2008,
I noticed we seem to have a problem with concurrent use of filesystem
operations - which often hang (waiting on a vn_lock()) or cause
assertion failures.

This trivial test - which does stat() calls in 10 concurrent threads -
reproduces this bug, and usually (but not always) crashes on one of
several assertion failures, or hangs.

Linux IOCTL commands in addition to the BSD IOCTLS. Linux IOCTLs should be
used instead of BSD IOCTLs whenever possible.

Most of this is just header shuffling.

ZFS will make use of this.

We leave out the taskqueues running in software interrupts (OSv doesn't have
this concept and most likely never will), as well as those having timeouts
(we can add those once needed)