the convention in linux is that argv[0] holds the program executable.
I had an attempt to run netserver not from the CLI and it didn't work because
its argument parsing got broken.

Added the possibility to pass to cli.jar a command, which it runs instead
of taking commands interactively. Note that the initialization script is
run before the given command.

After this patch,

        scripts/run.py -e "java.so -jar /java/cli.jar"

Continues to run the interactive command line editor loop, as before.
But additionally, one can do:

        scripts/run.py -e "java.so -jar /java/cli.jar ls"

To run just the command "ls" and exit - exactly as if the user would type
this command on the command line and exit the VM.

The given command can be, of course, much longer. For example to run Jetty
after the CLI's normal initialization script, the following monster can
be used:

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

(Funny how a single command should say "java" 3 times and "jetty" 4 times :-))

Add a "java" command to the CLI, using the same syntax of java.so and
attempting to emulate as closely as possible the "java" command on Linux.
So for example one can run

        java Hello

to run /java/Hello.class (/java is on the classpath by default), or

        java -jar /java/bench.jar

to run the main class of this jar, or a more sophisticated
command lines, such as the following which runs Jetty (if the
appropriate files are in your image):

        java -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration /jetty/jetty.xml

Note that like java.so, the new "java" command basically runs the RunJava
class (/java/RunJava.class). Remember that java.so adds /java to the parent
class loader, so we can always find the RunJava class even though it's not
in cli.jar or cloudius.jar).

This patch adds support for O_NONBLOCK on pipes and unix domain sockets.

Java's EPollSelectorImpl uses a pipe to interrupt a sleeping poll, and it,
quite understandably, sets them to non-blocking (if you only write a
single byte to a pipe, you don't expect any blocking anyway).
So we can't croak if this option is used, and better just implement it
correctly.

run_cmd.run() is an internal function that can be used by the rest of the cli.

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.

java.cc would exit right after the main() method finished. But in Java,
this is not the correct behavior. Rather, even if main() returns, we
need to wait for all other threads to end (or more accurately, wait
for all threads not marked with setDaemon(true)).

Calling jvm->DestroyJavaVM() does this for us, and it's probably the
Right Thing(TM) to do anyway.

Before this patch, the Jetty benchmark exited immediately after
startup.  After this patch, its worker threads keep the whole VM running.

Java doesn't trust pthread_getattr_np() to work for the main thread in
Linux, so instead it relies on a global variable __libc_stack_end, which
we didn't implement and therefore causing an annoying message.

This patch implements __libc_stack_end. Pardoxically, this shouldn't point
to the real stack end (we can easily find this our sched::thread interfaces)
but a little below it, because Java expects the address to be in the
stack, not one byte above it. So we use __builtin_frame_address(0) to
find the current frame's address.

Unfortunately, while this elliminates one warning message, another one
remains - because Java later expects to read /proc/self/maps and doesn't
find it.

The source file af_local.cc implemented both pipes and bi-directional
pipes (unix domain stream socketpair), using a common buffer implemetation.

As suggested by Guy, split this file into four files:

pipe_buffer.cc and pipe_buffer.hh contain the common buffer implementation,
class pipe_buffer. Since this buffer basically implements a single-direction
pipe, I renamed it from "af_local_buffer" to pipe_buffer.

af_local.cc now contains just the unix domain stream socketpair
implementation, implemented using two pipe_buffer objects.

af_pipe.cc contains the Posix pipe() implementation, implemented using
one pipe_buffer object..

The iovec iteration was broken, so both readv() and writev() on pipes
and unix-domain stream sockets didn't work. Fix it.

This patch fixes two behaviors of pipes and unix-domain stream socketpair,
which went against Posix and Linux standards

1. A blocking write() on a pipe needs to return only when the full write -
   is finished. It should not just write until the end of the pipe buffer
   and return - as we did in the previous code.

   This means that a long write() to a pipe can write the data in parts,
   waiting between them for a reader to read from the pipe.

2. As explained above, writes will be split into parts (and if there are
   multiple writers, get mixed with writes from other writers). But Posix
   also guarantees that short writes - up to 4096 bytes (PIPE_BUF==4096
   on Linux) - are *atomic*, and not be split up.
   In the previous code, if even 1 byte was available on the buffer,
   we wrote it. Now, if the write is short, we need to wait until the
   entire needed length is available.

Test atomic writes, long writes (should block until complete), readv
and writev on pipes. All of these fail at this point, and will be fixed
by the following commits.

O_NONBLOCK is not yet supported in our implementation of unix-domain
sockets or pipes, so until it is, abort() if it is used, instead of
silently ignoring this mode and doing something very different from
what the application expected.

condvar_wait() wrongly dropped the condvar's internal lock too early,
and accessed wr->t outside the lock, meaning that a concurrent wake()
could race with it. This bug was exposed in one of the pipe() tests.

This patch fixes this bug, by holding the internal lock throughout
the execution of condvar_wait(), dropping it temporarily only while
waiting.

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.

also, it's better to call poll_wake() with both POLLIN/OUT and
POLLRDNORM/POLLWRNORM, just to be on the safe side. seen a few
references in the jdk.

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

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.

We don't have temporary snapshots yet, and we probably never will have processes
that could exit.