Adapt devalarm to the new unset_alarm [2/2]
authorBarret Rhoden <brho@cs.berkeley.edu>
Fri, 15 Jul 2016 19:35:05 +0000 (15:35 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Tue, 19 Jul 2016 15:43:10 +0000 (11:43 -0400)
commitfa7fbab03bdecf3cbeb5469bff70795c76239ae4
tree0ecfedb582956672d60f3d47f15ccf8f332a91a9
parent3dd87aef5d43ce09b78807cd548ee11be97d86ee
Adapt devalarm to the new unset_alarm [2/2]

Devalarm was trying, and failing, to handle the old style of unset_alarm().
Specifically, in its kref release, it was freeing the memory after an
unset.  The unset would succeed, but the RKM was still pending.  I had this
happen; it was fun.

This also fixes a minor bug with firing FD taps outside the lock.  At
least it looked wrong.

All in all, I'm not super happy with the sync in use here.  Here's the
issue.  We need to sync between unset and set.  unset blocks, so we need
some sleeping sync.  We also need some sync between the handler and other
operations (e.g. on 'count' and the timerfd wakeup).  Since unset waits-on
the handler, we can't use the same sync for "unset-to-set" and
"handler-to-others".  Finally, we need something for the timerfd that
allows aborts, such as the CV (or maybe a hacked rendez, but that is just a
CV under the hood).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/drivers/dev/alarm.c
kern/include/devalarm.h