uthread_slim_init()

Allows the uthread code to manage thread0 in the absence of a 2LS.
Eventually, all processes will call uthread_slim_init(), which will be
useful for event delivery to _Ss.  Then processes that will become MCPs
will call uthread_lib_init and set up the full system (using 2LS
threads, instead of just struct uthreads).
uthread_vcore_entry() can handle not having a 2LS

_Ss that never link in a 2LS will pop up in vcore_entry() when receiving
events.  This patch allows them to restart current_uthread - sort of a
'default 2LS op'.  I thought of making it an actual member of
default_2ls_ops, but I didn't want 2LS writers to think it is actually a
real default choice for them.  It's just to make _S code work.
All apps now must link against parlib (XCC)

Glibc calls out to a low-level parlib function (vcore_event_init(), used
to enable event delivery of *all* processes) that needs to be linked in
to every binary, regardless of whether or not the process will be an
MCP.

In addition to linking against parlib, applications need to be built
with " -u force_parlib_symbols ", which forces the linker to find the
strong version of symbols weakly used in glibc's start.c.

All test code has these flags/libraries set, but external apps need it
too.  Busybox, in particular, needs the patch in tools/patches to force
linking with parlib.

Rebuild your cross compiler, and install-libs (esp before rebuilding
busybox).  At a minimum, you need to copy start.c to the glibc-2.14.1/
tree and rebuild.  If that doesn't make sense, then just do a full
rebuild of glibc.
Event delivery to _S procs

If an _S registers an ev_q, the kernel event delivery system will send
events to the process.  Events will go to vcore0's public mbox,
regardless of ev_flags, so long as the proc is an _S.  Processes can set
up ev_qs for whatever they want later, and then when they are MCPs, the
flags will kick in (and you don't have to change things).  That is how
processes should set up ev_qs for POSIX signals.

The code can also handle the process being descheduled, and the _S will
pop into vcore context when it starts up (if it wasn't already in vcore
context when it was stopped).

Receiving an event also should wake an _S, rescheduling it, though that
hasn't been tested yet (_Ss don't WAIT yet).
Fixes bug in event headers (XCC)

Has been around since 16a868, haven't seen it hit yet, though it might
have been masking other bugs.
Removed unnecessary/fauly assert

This safely trips if SCPs kthread and yield in a loop while waiting.
Here's what happens:
1) process causes a kthread (sys_block)
2) process yields, leaving the core (no longer current or owning)
3) timer interrupt goes off and unblocks the kthread, which sets current
(but not owning)
4) kthread does not clear current - that's done in the
restartcore/smp_idle path.
5) ksched's timer tick goes off, causing its work to be done in a
routine kmsg
6) proc_restartcore executes the kmsg before abanonding
&) ksched kmsg calls proc_run_s

We actually don't want to abandon early - it's better to stay in that
context til after we check messages (avoid an extra TLB flush).  The old
assert was probably important a long time ago (back when owning_proc and
current were the same thing), or at least a "this is weird, check it
out."

Note the process is current, but not the owning proc.
SCPs can register ev_qs for syscalls (XCC)

Right now, they just yield and get restarted right away, while waiting
for the event (and actually they just check the sysc flag).  Future
patches will have them become WAITING.

Rebuild your cross compiler/userspace.
SCPs can sleep on events (XCC)

If single-core processes yield that aren't 'being nice', they will block
waiting for an event.  Otherwise, the process is simply giving up the
processor for someone else, even though it has work to do.

The meaning of being_nice differs between SCPs and MCPs.  MCPs will
never give up if they have work to do, unless they think a preemption is
coming in.  Might consider getting rid of the whole SCP 'sched_yield'
approach (arguably, it's the kernel's job) for _Ss, but whatever.

Rebuild your cross compiler, making sure to replace sched_yield.c in
your glibc directory.  Otherwise, sched_yielders (like busybox) will
accidentally block.
Kernel can detect degenerate SCPs (XCC)

Meaning, the SCP can't go into vcore context yet (very early in the life
of a process).  Once userspace turns off the VC_SCP_NOVCCTX flag, the
kernel will put the SCP into vc ctx, when appropriate (notified).
Glibc syscalls now block properly (XCC)

Glibc wasn't calling out to the proper blockon call.  We deal with this
by having a default blockon, defined in glibc's syscall.c, that
degenerate SCPs can use.  Once they init enough and have access to
parlib symbols, they switch the function ptr to use the 'real' blockon,
which uses glibc's default one for SCPs.

Rebuild glibc and anything in userspace.
sys_trywait() now blocks

We actually need a real wait/waitpid() call, which will also allow us to
cleanup glibc's waitpid() and fork() calls.  For now, this will allow us
to have bb block on its children, instead of spinning.
Keyboard/char input buffering and irq handling

Each arch needs to have interrupt handlers for their console input that
call the appropriate routine kmsgs, which will handle putting the char
in the console buffer.  Take a look at x86's.  If this is somehow
fundamentally incompatible with RISCV, let me know.

This techincally adds to a kernel header, but no one should need to
rebuild anything.
Reading from /dev/stdin will block

We read one char at a time now (per syscall).  busybox asks for up to
1023, interestingly enough.  It also doesn't know it is a tty yet, so
I'm sure its behavior will change.  Note that we already fake a bunch of
TTY related things.  Not sure who is supposed to echo the key btw...

And we don't do anything like sending SIGINT or control characters.
Kernel now halts when there is no work

We had been polling in a variety of places.  This takes away the last
one: spinning in the manager().  Now, the manager doesn't get called
much (it gets called once, and that should be it).

Note that we still poll in the monitor(), which you can always get to
via 'G' (the call of the giraffe).  (so long as interrupts are enabled,
you're not stuck in a loop, etc).
Fixes static binary init issue (XCC)

Can't call vcore_event_init() before the other C runtime inits (runs
into issues with not having TLS initialized, which vcore_event_init()
needs (some malloc checks/init stuff)).

Rebuild glibc, copying over at least start.c.
Ksched preempts SCPs on schedule() calls

Also will check for SCPs to run when the core has nothing to do
(cpu_bored()), as opposed to waiting til the next timer tick.
Fixes serial interrupt enabling on x86 hardware

Qemu didn't need the bit set, but our desktops (16550(A)s) do.  Nice to
know that my old IO Ports list called that bit "auxiliary
user-designated output 2".  My bad for clobbering that bit (that was on
by default) when attempting to set the flow control.
x86 console/serial cleanup

Console devices (KB, serial) now have structs associated with them,
which we can later register with interrupt drivers.

Input devices can now get -1 (0xff) and 0.  Not a big deal for the
keyboard, but the serial device might actually get those 'chars' at some
point.

We also look for and initialize COM2, COM3, and COM4, as well as detect
the type of serial device.  For now, our output spams all of these (if
available).
x86 register IRQ handlers for devices that exist

Instead of just blindly registering anything that could exist.

Note that we can only register one 'device' per IRQ, so if you have both
COM1 and COM3 (for example, and let alone other devices sharing IRQs),
then the last one to register will get serviced.
PIC helper functions to read the ISR, IRR, and IMR

Remember, bit 2 (0x4) will be high on the ISR/IRR when any of the high 8
IRQs are high, due to the chaining of the PICs.  Likewise, the IRR will
show an IRQ when it is masked - the chip will simply never send it.

Also note that these only apply for interrupts coming in via the PIC,
and not the IOAPIC/LAPIC.  You'll need to check the LAPIC for its
ISR/IRR.