Fixes struct proc initialization

We weren't initialized the ksched_data.  Instead of adding that, or
using Ivy, we'll just memset the whole thing to 0, and then selectively
set whatever needs set (sometimes to 0 to be explicit).
Removes EBADPROC

Which is really ESRCH.  No real need to reinstall your kernel headers,
unless you happen to try to compile program that was using that error
number...
Fixes potential race with SCPs blocking (XCC)

If we ever received an event/notif after registering the ev_q and before
yielding, that event would cause us to clear notif_pending.  This would
cause us to sleep permanently in yield, since we already both received
the 'syscall done' event and marked its reception.

If you want to write similar code, the important thing was that we need
notifs disabled before we check the syscall's SC_DONE.
POSIX signal sending / reception (XCC)

Adds kernel support for basic POSIX inter-process signals.  We just
multiplex signals through a new Event type.  There's a kernel helper to
send signals, if you want.

Uthread code registers an ev_q for the signals, and right now just has a
dummy handler.  We'll need to hook this in to glibc for support of all
the usual signal-related functions.

Also, grab the new busybox config - it supports kill.

Rebuild your cross compiler/kernel headers and anything that linked
against parlib (like busybox).
Parent processes track children

Instead of relying on just the child having the ppid number.  Plus,
there's a little more info in the monitor commands (ps, procinfo), and
trywait was cleaned up a bit.

If the comment about why children don't keep pointers to their parents
doesn't make sense, look over the kref Documentation and think about how
we could ever safely disown a child (like if a parent terminates first).
Fixes RESET_STACKS

Need to not inline __smp_idle(), o/w the set_stack_pointer mucks with
things (specifically, it was mucking with the first word of the previous
page, which was often kthread poison).
kthread_yield()

Caller is suspended in a kthread, and will get woken up via RKM to the
calling core.  In essence, it pauses the kthread and allows other RKMs
to run.

If the ksched does anything fancy, we could do other things, like send
the kthread to another core.
Semaphore upping done with irqsave

So this isn't actually necessary, but might help us in the future.

If the semaphore is never locked and then potentially interrupted, then
we're okay.  sleep_on() disables IRQs.  If there is only one IRQ handler
that ups a particular sem, then we also aren't in danger of deadlocking.

Anyway, __up_sem() is being used in a bunch of places, and might be used
somewhere in the future that could have an issue with irqsaving.  Like
if process context code was calling __up_sem() *and* there was one IRQ
handler calling __up_sem(), then we could deadlock.
Condition variables

Built with semaphores.  This is notoriously tricky, and I might not have
done it correctly.

See http://research.microsoft.com/pubs/64242/implementingcvs.pdf for a
discussion of some of the issues.

I get around it by peaking in the semaphore and using its count as a
'lock' to enforce an ordering on waiters so that the order in which you
hit the CV is the order that you hit the internal sem.  And since it's
the sem's count, we can atomically sleep on the sem and 'release' that
'lock'.
sys_waitpid() improvements (XCC)

Cleans up the glibc fork/wait mess by supporting waitpid(-1).  This will
allow shells (busybox/ash) to do some decent job control with
backgrounding tasks.  Previously, we'd wait on our children in order,
instead of waiting on any available child.

This does not handle concurrent wait calls from the parent (even SCPs
could do async calls).  I'm working on that, and will have it in another
commit to serve as an example of the pain caused by concurrent process
management syscalls (whether due to async syscalls by an SCP or parallel
calls from an MCP).

Rebuild glibc.
Fixes sys_waitpid() to handle concurrent waiters

As mentioned before, we could have concurrent syscalls from the parent
waiting on a child or any child.  The issues were trying to reap a child
that has been already reaped (by a -1 or a particular wait call), and
having the children list get emptied while sleeping (for waitpid(-1)).
Additionally, we had to be careful about syscalls blocking and never
getting a wakeup signal.

None of our apps do multiple waiting syscalls, so I haven't tested the
corner cases.

This all is an example of complications arising with concurrent syscalls in
code that would be easier with just synchronous SCPs.  Not a
deal-breaker, just a minor pain.
Fixes irqsave issue with CVs

Using spinlock_irqsave like that isn't sufficient.  The spinlock_irqsave
really only works across a single lock/unlock pair (it saves the irq
state in the lock).  When we unlock, we potentially reenable irqs.

During the while loop (which enforces ordering), we basically are
holding a sort of lock.  Signallers run from irq context could interrupt
us, deadlocking the system.

Instead, we just have the caller of the CV tell us if we want IRQs off
or not.  Pay attention to the note in trap.c.

In the future, I might rewrite the kthread code to use CVs instead of
semaphores, which would get rid of the while loop/ordering.  Regardless,
I still prefer having the cv_*_irqsave() functions.
Changes semaphore API

There now is an irqsave API, same as CVs.  All semaphore users need to
change and use irqsave if they will be called from irq context.  This
also renames sleep_on() to sem_down().  There's no awesome way to name
it, other than to know what it means to down a semaphore.

Also, we now only disable irqs when blocking a kthread for the smallest
amount of time (unless its irqsave): when we need to atomically sleep
and change to a new thread (stack).
Removes SPARC ifdefs from blockdev code

If SPARC or any other arch can't kthread, then many other things won't
work and that needs to be fixed ASAP.
Kernel message nested function scoping

Sometimes when we define kernel message functions inside another
function, the compiler will put function's code on the stack.

This happens now with the __test_cv functions in testing.c.  It doesn't
seem to do it for others, and as far as I can tell, it will do so when
the function references stack variables.  Makes sense, since
stack-relative addresses are the only way to know where the variables
are.

Anyway, I don't know if the compiler will ever put those functions on
the stack for other reasons.  Since it's probably a bad idea to refer to
items after their scope disappears, move the KMSG handlers outside the
scope of their caller.  If you don't, be careful.

It's tempting to use some form of synchronization to keep the
encapsulating function alive til the handlers complete, say with a flag
variable or something (which we tend to do anyways).  However, there's
still a slight race after the handler function signals and before that
code returns/pops its stack frame.