Kernel alarms pass the alarm ID
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 26 Nov 2013 02:06:20 +0000 (18:06 -0800)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 16 Jan 2014 21:07:51 +0000 (13:07 -0800)
commitd06aeb048b638f4ff5f045993284e030a5cfbd90
tree3e2f69ac71a931e99e7de06d94634d49279c62af
parentfa582d5ea66336332a670e2c6cf6a1e23cd2a13d
Kernel alarms pass the alarm ID

So userspace can tell which of it's #A alarms is firing.  With this (and
with multiple event handlers per event), we could have multiple alarm
handlers register and run dynamically.  Alternatively, we could switch
based on the ID, if there was one common handler (can do that
statically).

Note that the existing alarm examples can receive multiple events for
the same alarm.  It's up to userspace to handle that (it's easy, and we
do it).  This is a consequence of using SPAM_PUBLIC.  If your alarm
can't handle that, use an INDIR/FALLBACK.  This is part of the reason
why I didn't make a helper to set up all the alarm stuff - people will
want to customize, especially in the realm of the ev_q.  (The other
issue is whether or not CLOEXEC is used.  And there may be other issues
I haven't thought of).

Multiple ev_qs can be registered for different alarms; it's just hard to
share the event handler for them all, hence this patch.  I'll deal with
this more if we ever get someone who wants to use multiple kernel alarms
with different handlers.
kern/drivers/dev/alarm.c
tests/alarm.c
user/benchutil/alarm.c
user/benchutil/include/alarm.h