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.

It clashes with a macro of the same name in OSv.

OSv isn't ready for this yet.

Previous commit broke the build, because I forgot to commit a file.

Previously, we re-implemented "unsupported" file operations (e.g., chmod
for a pipe on which fchmod makes no sense) several times - there was
an implementation only for chmod in kern_descrip.c, used in sys_socket.c,
and af_local.cc had its own. As we add more file descriptor type (e.g.,
create_epoll()) we'll have even more copies of these silly functions, so
let's do it once in fs/unsupported.c - with the fs/unsupported.h header
file.

This also gives us a central place to document (and argue) whether an
unimplemented ioctl() should return ENOTTY or EBADF (I think the former).

If poll() was waiting on a file descriptor from socketpair_af_local, we
would never wake it up, and an example of this is the failure in a
recently committed fix to tst-af-local.cc.

The problem is that when one writes to one end of the socket, we need to
call wake_poll() on the other end of the socket, so we need to remember
which "struct file *" is attached to each end of the af_local_buffer objects.

What I did is what I thought the most elegant solution is:

Rather than having "sender" and "receiver" of af_local_buffer booleans,
they are now "struct file *". I added new functions, attach_sender(f) and
attach_receiver(f), which set the file* we'll need to notify for each
end; These functions are analogous to functions detach_sender, detach_receiver
that we already had.

After each interesting event - read, write, close, etc - we notify the
appropriate file*, using poll_wake.

attach_sender(f) and attach_receiver(f) is called by af_local_init(f) - which
used to be empty and now does something. Note how af_local_init(f) only
does send->attach_sender(f) and receive->attach_receiver(f), but doesn't
touch the two others (send->attach_receiver, receive->attach_sender) -
these other two are set when the second file descriptor, with the send
and receive fifos in reversed roles, is initialized with its af_local_init.

After this fix, the new af_local_test works correctly.

The tst-af-local.so test supposedly tested a waiting poll() on a
unix-domain socketpair, but unfortunately the test was incorrect - the
writer thread usually (even always) manged to write to the socket before
poll() started, so poll() never actually had to wait and always returned
immediately.

But it turns out, when we really do need to wait, there *is* a bug:
poll() doesn't wake up when input arrives. So this patch fixes the *test*
to demonstrate the bug. After this fix, the tst-af-local.so test now fails.
I'll fix the bug, to make the test pass again, in a followup patch.

Don't abort on an unimplemented sysconf parameter. One of the documented
functions of sysconf(3) is to "test ... whether certain options are
supported", so programs are free to test for features we don't support
yet, and we're supposed to return -1 with errno set to EINVAL.

For example, Boost tested _SC_THREAD_SAFE_FUNCTIONS which we didn't
support. It would have been fine if we set EINVAL (it would switch
from *_r functions to the non-reenatrant ones) - but it wasn't fine
that we abort()ed because of this test :-)

To be on the safe side, this patch still prints a message if we see an
unknown sysconf - in case in the future we'll come across a new one we
must treat. But eventually, the message should go away too.

Implement the _SC_THREAD_SAFE_FUNCTIONS sysconf, returning 1.

_SC_THREAD_SAFE_FUNCTIONS is defined in Posix 1003.1c ("posix threads"),
and is supposed to return 1 if the thread-safe functions option is
supported (*_r() functions). Since we do implement those, we should return
1 for this sysconf.

Boost's system library uses this sysconf, and if it sees it is not
available, restorts to the _r()-less variants, for no good reason.

This patch implements readdir64, as an alias to readdir. We can do this,
because on 64-bit Linux, even the ordinary struct dirent uses 64-bit
sizes, so the structures are identical.

The reason we didn't miss this function earlier is that reasonable
applications prefer to use readdir64_r, not readdir64. Because Boost
filesystem library thought we don't have the former (see next patch
for fixing this), it used the latter.

Say we also implement librt.so.1. This is required, for example, by the
Boost libraries (e.g., libboost_system-mt.so.1.50.0). The librt library
isn't actually a separate library on modern Linux - rather all its
traditional functions are now in glibc, and "librt" is merely a filter
on glibc. So no reason not to say we support librt too.

Not to mention that we already implement a bunch of functions that
traditionally resided in librt (nanosleep, sched_yield, sem_*, etc.

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.

getsockname() used to fail because by the time the call chain reached
kern_getsockname() it got addrlen=0. The problem is getsockname1()
which gives it an initialized local variable instead of the given
addrlen.

Most of these layers and copies are redundant, and are only left because
of previous incarnations of the code which had copies from user space -
but we need to at least get the unnecessary copies right ;-)

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"

mkbootfs.py supports wildcard entries, looking like:
/jetty/**: ../../../tmp/jetty/**

The name of the generated files in the bootfs looked like this:
                name + relpath + '/' + filename

where "name" is "/jetty/", relpath is the directory under it
(so for /jetty/foo/bar/yo, relpath is "foo/bar") and filename
is the file name (in this example "yo"). The problem is that
when relpath=="", i.e., files directly under /jetty, an extra
slash was generated - e.g., /jetty//something. When this extra
slash was written to the filesystem it confused readdir(),
causing it to return twice for each file (once with an empty
filename, and a second time with the real filename).

This patch avoid the extra slash when relpath is empty.

needed for the next patch, which implements osv memory

When some code section happens to be called from both thread context and
interrupt context, and we need mutual exclusion (we don't want the interrupt
context to start while the critical section is in the middle of running in
thread context), we surround the critical code section with CLI and STI.

But we need the compiler to assure us that writes to memory done between
the calls to CLI and STI stay between them. For example, if we have

    thread context:                 interrupt handler:

      CLI;                          a--;
      a++;
      STI;

We don't want the a++ to be moved by the compiler before the CLI. We also
don't want the compiler to save a's value in a register and only actually
write it back to the memory location 'a' after the STI (when an interrupt
handler might be concurrently writing). We also don't want the compiler
to remember a's last value in a register and use it again after the next
CLI.

To ensure these things, we need the "memory clobber" option on both the CLI
and STI instructions. The "volatile" keyword is not enough - it guarantees
that the instruction isn't deleted or moved, but not that stuff that
should have been in memory isn't just in registers.

Note that Linux also has these memory clobbers on sti() and cli().
Linus Torvals explains in a post from 1996 why these were necessary:
http://lkml.indiana.edu/hypermail/linux/kernel/9605/0214.html

All that being said, we never noticed a bug caused by the missing
"memory" clobbers. But better safe than sorry....