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....

the new test creates several thread, each is downloading a ~280MB file
concurrently. It aims to find concurrency bugs in the netport, dead locks,
etc... but (fortunately) it pass.

Optimize fsbase reload using the wrfsbase instruction, where available.

making it even more stressful ;)

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

ZFS wants direct access to a global utsname structure.  Provide one from
core OSv code and rewrite uname to just copy it out.  To ease this move
the uname implementation to a C file as this allows using designated
initializers and avoids the casting mess around memcpy.

the debug() console function is taking a lock before it access the console driver,
it does that by acquiring a mutex which may sleep.

since we want to be able to debug (and abort) in contexts where it's not possible sleep,
such as in page_fault, a lockless debug print method is introduced.

previousely to this patch, any abort on page_fault would cause an "endless" recursive
abort() loop which hanged the system in a peculiar state.

the current code handles the case of recursive aborts incorrectly, while
the existing comment is very precise :)

This allows to remove various #if 0'ed code using vnode_t or znode_t to be
compiled, both in the current headers and future ported code.

BSD and Solaris code likes to pass this identifier for the "kernel" process
to various thread creation routines.  Make our life simpler by providing it
and ignoring it.

The comment about unlocking the irq_lock was put on the wrong line.
Move it (and rephrase it a bit - the word "release" immediately after
calling an unrelated release() function - is confusing).

yield() had two bugs - thanks to Avi for pinpointing them:

1. It used runqueue.push_back() to put the thread on the run queue, but
   push_back() is a low-level function which can only be used if we're
   sure that the item we're pushing has the vruntime suitable for being
   *last* on the queue - and in the code we did nothing to ensure this
   is the case (we should...). So use insert_equal(), not push_back().

2. It was wrongly divided into two separate sections with interrupts
   disabled. The scheduler code is run both at interrupt time (e.g.,
   preempt()) and at thread time (e.g., wait(), yield(), etc.) so to
   guarantee it does not get called in the middle of itself, it needs
   to disable interrupts while working on the (per-cpu) runqueue.
   In the broken yield() code, we disabled interupts while adding the
   current thread to the run queue, and then again to reschedule.
   Between those two critical sections, an interrupt could arrive and
   do something with this thread (e.g., migrate it to another CPU, or
   preempt it), yet when the interrupt returns yield continues to run
   reschedule_from_interrupt which assumes that this thread is still
   running, and definitely not on the run queue.

Bug 2 is what caused the crashes in the tst-yield.so test. The fix is
to hold the interrupts disabled throughout the entire yield().
This is easiest done with with lock_guard, which simplifies the flow
of this function.

Because of Linux's calling convention, it should not be necessary to
save the FPU state when a reschedule is caused by a function call.

Because we had a bug and forgot to save the FPU state when calling
a signal handler, and because this signal handler can cause a reschedule,
we had to save the FPU on any reschedule. But after fixing that bug, we
no longer need these unnecessary FPU saves.

The "sunflow" benchmark still runs well after this patch.

Drops context switch time by ~80ns.

Faster way to write fsbase on newer processors.

This are used to support ifunc functions, which are resolved at load-time
based on cpu features, rather than at link time.