FALLBACK logic -> spam_public_msg() (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 7 Dec 2011 22:30:10 +0000 (14:30 -0800)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 15 Dec 2011 22:48:41 +0000 (14:48 -0800)
commit7ea33f86f6a68dd79df2aabd94e95259d1217ab5
tree46cd95c5c9f6a64f3a43e412ea7064facca98c82
parent66d8cdd982dcceb8de36d33b3584f7d442d7a5db
FALLBACK logic -> spam_public_msg() (XCC)

The old logic behind the FALLBACK aspects of alert_vcore(), which was
used to make sure INDIRs made it to a (optionall running) vcore is now
more generic, and is callable for arbitrary ev_msgs, not just INDIRs.
INDIRs still benefit from this, and they call it at the bottom of
send_indir().  Other messages (e.g. preemption, in future patches) can
use it to get the same delivery guarantee: your message will get spammed
to vcores until we're sure at least one of them got it and will read it.

The VCORE_MUST_RUN flag is still supported.  It means that when
spamming, we pick vcores that must be running, compared to settling for
a vcore that will eventually get looked at (during preemption recovery).

Note that there is no way in this patch for userspace to access the
spam_public_msg().

Trivial change to the kernel header (ros/event.h) - userspace doesn't
use it yet, and might not ever.
kern/include/ros/event.h
kern/src/event.c