d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
90de864a5e
freebsd-skq/sys/kern/subr_eventhandler.c

281 lines
8.5 KiB
C
Raw Normal View History

Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
/*-
* Copyright (c) 1999 Michael Smith <msmith@freebsd.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
Use __FBSDID().
2003-06-11 00:56:59 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
#include <sys/param.h>
#include <sys/kernel.h>
Catch up to header include changes: - <sys/mutex.h> now requires <sys/systm.h> - <sys/mutex.h> and <sys/sx.h> now require <sys/lock.h>
2001-03-28 09:17:56 +00:00
#include <sys/lock.h>
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
#include <sys/malloc.h>
- Convert the per-eventhandler list mutex to a lockmgr lock so that it can be safely held across an eventhandler function call. - Fix an instance of the head of an eventhandler list being read without the lock being held. - Break down and use a SYSINIT at the new SI_SUB_EVENTHANDLER to initialize the eventhandler global mutex and the eventhandler list of lists rather than using a non-MP safe initialization during the first call to eventhandler_register(). - Add in a KASSERT() to eventhandler_register() to ensure that we don't try to register an eventhandler before things have been initialized.
2000-12-12 04:01:35 +00:00
#include <sys/mutex.h>
Undo part of the tangle of having sys/lock.h and sys/mutex.h included in other "system" header files. Also help the deprecation of lockmgr.h by making it a sub-include of sys/lock.h and removing sys/lockmgr.h form kernel .c files. Sort sys/*.h includes where possible in affected files. OK'ed by: bde (with reservations)
2001-05-01 08:13:21 +00:00
#include <sys/proc.h>
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
#include <sys/systm.h>
#include <sys/eventhandler.h>
Staticize some malloc M_ instances.
2000-12-08 20:09:00 +00:00
static MALLOC_DEFINE(M_EVENTHANDLER, "eventhandler", "Event handler records");
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
/* List of 'slow' lists */
Back out the previous change to the queue(3) interface. It was not discussed and should probably not happen. Requested by: msmith and others
2000-05-26 02:09:24 +00:00
static TAILQ_HEAD(, eventhandler_list) eventhandler_lists;
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
static int eventhandler_lists_initted = 0;
- Make the eventhandler_mutex mutex a private variable in subr_eventhandler.c - Move the extra #include's in sys/eventhandler.h to be protected by the #ifndef SYS_EVENTHANDLER/#endif
2000-10-25 00:01:39 +00:00
static struct mtx eventhandler_mutex;
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
struct eventhandler_entry_generic
{
struct eventhandler_entry ee;
void (* func)(void);
};
Use 'const char *' for a few prototypes. Reviewed by: ru
2004-12-06 10:53:40 +00:00
static struct eventhandler_list *_eventhandler_find_list(const char *name);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
- Convert the per-eventhandler list mutex to a lockmgr lock so that it can be safely held across an eventhandler function call. - Fix an instance of the head of an eventhandler list being read without the lock being held. - Break down and use a SYSINIT at the new SI_SUB_EVENTHANDLER to initialize the eventhandler global mutex and the eventhandler list of lists rather than using a non-MP safe initialization during the first call to eventhandler_register(). - Add in a KASSERT() to eventhandler_register() to ensure that we don't try to register an eventhandler before things have been initialized.
2000-12-12 04:01:35 +00:00
/*
* Initialize the eventhandler mutex and list.
*/
static void
eventhandler_init(void *dummy __unused)
{
TAILQ_INIT(&eventhandler_lists);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
mtx_init(&eventhandler_mutex, "eventhandler", NULL, MTX_DEF);
atomic_store_rel_int(&eventhandler_lists_initted, 1);
- Convert the per-eventhandler list mutex to a lockmgr lock so that it can be safely held across an eventhandler function call. - Fix an instance of the head of an eventhandler list being read without the lock being held. - Break down and use a SYSINIT at the new SI_SUB_EVENTHANDLER to initialize the eventhandler global mutex and the eventhandler list of lists rather than using a non-MP safe initialization during the first call to eventhandler_register(). - Add in a KASSERT() to eventhandler_register() to ensure that we don't try to register an eventhandler before things have been initialized.
2000-12-12 04:01:35 +00:00
}
SYSINIT(eventhandlers, SI_SUB_EVENTHANDLER, SI_ORDER_FIRST, eventhandler_init,
In keeping with style(9)'s recommendations on macros, use a ';' after each SYSINIT() macro invocation. This makes a number of lightweight C parsers much happier with the FreeBSD kernel source, including cflow's prcc and lxr. MFC after: 1 month Discussed with: imp, rink
2008-03-16 10:58:09 +00:00
NULL);
- Convert the per-eventhandler list mutex to a lockmgr lock so that it can be safely held across an eventhandler function call. - Fix an instance of the head of an eventhandler list being read without the lock being held. - Break down and use a SYSINIT at the new SI_SUB_EVENTHANDLER to initialize the eventhandler global mutex and the eventhandler list of lists rather than using a non-MP safe initialization during the first call to eventhandler_register(). - Add in a KASSERT() to eventhandler_register() to ensure that we don't try to register an eventhandler before things have been initialized.
2000-12-12 04:01:35 +00:00
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
/*
* Insertion is O(n) due to the priority scan, but optimises to O(1)
* if all priorities are identical.
*/
Split eventhandler_register() into an internal part and a wrapper function that provides the allocated and setup eventhandler entry. Add a new wrapper for VIMAGE that allocates extra space to hold the callback function and argument in addition to an extra wrapper function. While the wrapper function goes as normal callback function the argument points to the extra space allocated holding the original func and arg that the wrapper function can then call. Provide an iterator function for the virtual network stack (vnet) that will call the callback function for each network stack. Provide a new set of macros for VNET that in the non-VIMAGE case will just call eventhandler_register() while in the VIMAGE case it will use vimage_eventhandler_register() passing in the extra iterator function but will only register once rather than per-vnet. We need a special macro in case we are interested in the tag returned as we must check for curvnet and can neither simply assign the return value, nor not change it in the non-vnet0 case without that. Sponsored by: ISPsystem Discussed with: jhb Reviewed by: zec (earlier version), jhb MFC after: 1 month
2010-03-19 19:51:03 +00:00
static eventhandler_tag
eventhandler_register_internal(struct eventhandler_list *list,
const char *name, eventhandler_tag epn)
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
{
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
struct eventhandler_list *new_list;
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
struct eventhandler_entry *ep;
- Convert the per-eventhandler list mutex to a lockmgr lock so that it can be safely held across an eventhandler function call. - Fix an instance of the head of an eventhandler list being read without the lock being held. - Break down and use a SYSINIT at the new SI_SUB_EVENTHANDLER to initialize the eventhandler global mutex and the eventhandler list of lists rather than using a non-MP safe initialization during the first call to eventhandler_register(). - Add in a KASSERT() to eventhandler_register() to ensure that we don't try to register an eventhandler before things have been initialized.
2000-12-12 04:01:35 +00:00
KASSERT(eventhandler_lists_initted, ("eventhandler registered too early"));
Split eventhandler_register() into an internal part and a wrapper function that provides the allocated and setup eventhandler entry. Add a new wrapper for VIMAGE that allocates extra space to hold the callback function and argument in addition to an extra wrapper function. While the wrapper function goes as normal callback function the argument points to the extra space allocated holding the original func and arg that the wrapper function can then call. Provide an iterator function for the virtual network stack (vnet) that will call the callback function for each network stack. Provide a new set of macros for VNET that in the non-VIMAGE case will just call eventhandler_register() while in the VIMAGE case it will use vimage_eventhandler_register() passing in the extra iterator function but will only register once rather than per-vnet. We need a special macro in case we are interested in the tag returned as we must check for curvnet and can neither simply assign the return value, nor not change it in the non-vnet0 case without that. Sponsored by: ISPsystem Discussed with: jhb Reviewed by: zec (earlier version), jhb MFC after: 1 month
2010-03-19 19:51:03 +00:00
KASSERT(epn != NULL, ("%s: cannot register NULL event", __func__));
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
Make the EVENTHANDLER mechanism MP-safe. Events can now be invoked without holding the Giant lock.
2000-09-22 03:17:35 +00:00
/* lock the eventhandler lists */
Change and clean the mutex lock interface. mtx_enter(lock, type) becomes: mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks) mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized) similarily, for releasing a lock, we now have: mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN. We change the caller interface for the two different types of locks because the semantics are entirely different for each case, and this makes it explicitly clear and, at the same time, it rids us of the extra `type' argument. The enter->lock and exit->unlock change has been made with the idea that we're "locking data" and not "entering locked code" in mind. Further, remove all additional "flags" previously passed to the lock acquire/release routines with the exception of two: MTX_QUIET and MTX_NOSWITCH The functionality of these flags is preserved and they can be passed to the lock/unlock routines by calling the corresponding wrappers: mtx_{lock, unlock}_flags(lock, flag(s)) and mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN locks, respectively. Re-inline some lock acq/rel code; in the sleep lock case, we only inline the _obtain_lock()s in order to ensure that the inlined code fits into a cache line. In the spin lock case, we inline recursion and actually only perform a function call if we need to spin. This change has been made with the idea that we generally tend to avoid spin locks and that also the spin locks that we do have and are heavily used (i.e. sched_lock) do recurse, and therefore in an effort to reduce function call overhead for some architectures (such as alpha), we inline recursion for this case. Create a new malloc type for the witness code and retire from using the M_DEV type. The new type is called M_WITNESS and is only declared if WITNESS is enabled. Begin cleaning up some machdep/mutex.h code - specifically updated the "optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently need those. Finally, caught up to the interface changes in all sys code. Contributors: jake, jhb, jasone (in no particular order)
2001-02-09 06:11:45 +00:00
mtx_lock(&eventhandler_mutex);
Make the EVENTHANDLER mechanism MP-safe. Events can now be invoked without holding the Giant lock.
2000-09-22 03:17:35 +00:00
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
/* Do we need to find/create the (slow) list? */
if (list == NULL) {
/* look for a matching, existing list */
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
list = _eventhandler_find_list(name);
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
/* Do we need to create the list? */
if (list == NULL) {
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
mtx_unlock(&eventhandler_mutex);
new_list = malloc(sizeof(struct eventhandler_list) +
strlen(name) + 1, M_EVENTHANDLER, M_WAITOK);
/* If someone else created it already, then use that one. */
mtx_lock(&eventhandler_mutex);
list = _eventhandler_find_list(name);
if (list != NULL) {
free(new_list, M_EVENTHANDLER);
} else {
CTR2(KTR_EVH, "%s: creating list \"%s\"", __func__, name);
list = new_list;
list->el_flags = 0;
list->el_runcount = 0;
bzero(&list->el_lock, sizeof(list->el_lock));
list->el_name = (char *)list + sizeof(struct eventhandler_list);
strcpy(list->el_name, name);
TAILQ_INSERT_HEAD(&eventhandler_lists, list, el_link);
Make the EVENTHANDLER mechanism MP-safe. Events can now be invoked without holding the Giant lock.
2000-09-22 03:17:35 +00:00
}
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
}
}
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
if (!(list->el_flags & EHL_INITTED)) {
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
TAILQ_INIT(&list->el_entries);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
mtx_init(&list->el_lock, name, "eventhandler list", MTX_DEF);
atomic_store_rel_int(&list->el_flags, EHL_INITTED);
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
}
Avoid a lock order reversal by dropping the eventhandler_mutex earlier. We get enough protection from the lock on the individual lists that we aquire later. Noticed/Tested by: Steven G. Kargl <kargl@troutmask.apl.washington.edu> Submitted by: Jonathan Mini <mini@haikugeek.com>
2002-04-04 00:52:03 +00:00
mtx_unlock(&eventhandler_mutex);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
Split eventhandler_register() into an internal part and a wrapper function that provides the allocated and setup eventhandler entry. Add a new wrapper for VIMAGE that allocates extra space to hold the callback function and argument in addition to an extra wrapper function. While the wrapper function goes as normal callback function the argument points to the extra space allocated holding the original func and arg that the wrapper function can then call. Provide an iterator function for the virtual network stack (vnet) that will call the callback function for each network stack. Provide a new set of macros for VNET that in the non-VIMAGE case will just call eventhandler_register() while in the VIMAGE case it will use vimage_eventhandler_register() passing in the extra iterator function but will only register once rather than per-vnet. We need a special macro in case we are interested in the tag returned as we must check for curvnet and can neither simply assign the return value, nor not change it in the non-vnet0 case without that. Sponsored by: ISPsystem Discussed with: jhb Reviewed by: zec (earlier version), jhb MFC after: 1 month
2010-03-19 19:51:03 +00:00
KASSERT(epn->ee_priority != EHE_DEAD_PRIORITY,
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
("%s: handler for %s registered with dead priority", __func__, name));
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
/* sort it into the list */
Split eventhandler_register() into an internal part and a wrapper function that provides the allocated and setup eventhandler entry. Add a new wrapper for VIMAGE that allocates extra space to hold the callback function and argument in addition to an extra wrapper function. While the wrapper function goes as normal callback function the argument points to the extra space allocated holding the original func and arg that the wrapper function can then call. Provide an iterator function for the virtual network stack (vnet) that will call the callback function for each network stack. Provide a new set of macros for VNET that in the non-VIMAGE case will just call eventhandler_register() while in the VIMAGE case it will use vimage_eventhandler_register() passing in the extra iterator function but will only register once rather than per-vnet. We need a special macro in case we are interested in the tag returned as we must check for curvnet and can neither simply assign the return value, nor not change it in the non-vnet0 case without that. Sponsored by: ISPsystem Discussed with: jhb Reviewed by: zec (earlier version), jhb MFC after: 1 month
2010-03-19 19:51:03 +00:00
CTR4(KTR_EVH, "%s: adding item %p (function %p) to \"%s\"", __func__, epn,
((struct eventhandler_entry_generic *)epn)->func, name);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
EHL_LOCK(list);
TAILQ_FOREACH(ep, &list->el_entries, ee_link) {
if (ep->ee_priority != EHE_DEAD_PRIORITY &&
Split eventhandler_register() into an internal part and a wrapper function that provides the allocated and setup eventhandler entry. Add a new wrapper for VIMAGE that allocates extra space to hold the callback function and argument in addition to an extra wrapper function. While the wrapper function goes as normal callback function the argument points to the extra space allocated holding the original func and arg that the wrapper function can then call. Provide an iterator function for the virtual network stack (vnet) that will call the callback function for each network stack. Provide a new set of macros for VNET that in the non-VIMAGE case will just call eventhandler_register() while in the VIMAGE case it will use vimage_eventhandler_register() passing in the extra iterator function but will only register once rather than per-vnet. We need a special macro in case we are interested in the tag returned as we must check for curvnet and can neither simply assign the return value, nor not change it in the non-vnet0 case without that. Sponsored by: ISPsystem Discussed with: jhb Reviewed by: zec (earlier version), jhb MFC after: 1 month
2010-03-19 19:51:03 +00:00
epn->ee_priority < ep->ee_priority) {
TAILQ_INSERT_BEFORE(ep, epn, ee_link);
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
break;
}
}
if (ep == NULL)
Split eventhandler_register() into an internal part and a wrapper function that provides the allocated and setup eventhandler entry. Add a new wrapper for VIMAGE that allocates extra space to hold the callback function and argument in addition to an extra wrapper function. While the wrapper function goes as normal callback function the argument points to the extra space allocated holding the original func and arg that the wrapper function can then call. Provide an iterator function for the virtual network stack (vnet) that will call the callback function for each network stack. Provide a new set of macros for VNET that in the non-VIMAGE case will just call eventhandler_register() while in the VIMAGE case it will use vimage_eventhandler_register() passing in the extra iterator function but will only register once rather than per-vnet. We need a special macro in case we are interested in the tag returned as we must check for curvnet and can neither simply assign the return value, nor not change it in the non-vnet0 case without that. Sponsored by: ISPsystem Discussed with: jhb Reviewed by: zec (earlier version), jhb MFC after: 1 month
2010-03-19 19:51:03 +00:00
TAILQ_INSERT_TAIL(&list->el_entries, epn, ee_link);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
EHL_UNLOCK(list);
Split eventhandler_register() into an internal part and a wrapper function that provides the allocated and setup eventhandler entry. Add a new wrapper for VIMAGE that allocates extra space to hold the callback function and argument in addition to an extra wrapper function. While the wrapper function goes as normal callback function the argument points to the extra space allocated holding the original func and arg that the wrapper function can then call. Provide an iterator function for the virtual network stack (vnet) that will call the callback function for each network stack. Provide a new set of macros for VNET that in the non-VIMAGE case will just call eventhandler_register() while in the VIMAGE case it will use vimage_eventhandler_register() passing in the extra iterator function but will only register once rather than per-vnet. We need a special macro in case we are interested in the tag returned as we must check for curvnet and can neither simply assign the return value, nor not change it in the non-vnet0 case without that. Sponsored by: ISPsystem Discussed with: jhb Reviewed by: zec (earlier version), jhb MFC after: 1 month
2010-03-19 19:51:03 +00:00
return(epn);
}
eventhandler_tag
eventhandler_register(struct eventhandler_list *list, const char *name,
void *func, void *arg, int priority)
{
struct eventhandler_entry_generic *eg;
/* allocate an entry for this handler, populate it */
eg = malloc(sizeof(struct eventhandler_entry_generic), M_EVENTHANDLER,
M_WAITOK | M_ZERO);
eg->func = func;
eg->ee.ee_arg = arg;
eg->ee.ee_priority = priority;
return (eventhandler_register_internal(list, name, &eg->ee));
}
#ifdef VIMAGE
struct eventhandler_entry_generic_vimage
{
struct eventhandler_entry ee;
vimage_iterator_func_t func; /* Vimage iterator function. */
struct eventhandler_entry_vimage v_ee; /* Original func, arg. */
};
eventhandler_tag
vimage_eventhandler_register(struct eventhandler_list *list, const char *name,
void *func, void *arg, int priority, vimage_iterator_func_t iterfunc)
{
struct eventhandler_entry_generic_vimage *eg;
/* allocate an entry for this handler, populate it */
eg = malloc(sizeof(struct eventhandler_entry_generic_vimage),
M_EVENTHANDLER, M_WAITOK | M_ZERO);
eg->func = iterfunc;
eg->v_ee.func = func;
eg->v_ee.ee_arg = arg;
eg->ee.ee_arg = &eg->v_ee;
eg->ee.ee_priority = priority;
return (eventhandler_register_internal(list, name, &eg->ee));
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
}
Split eventhandler_register() into an internal part and a wrapper function that provides the allocated and setup eventhandler entry. Add a new wrapper for VIMAGE that allocates extra space to hold the callback function and argument in addition to an extra wrapper function. While the wrapper function goes as normal callback function the argument points to the extra space allocated holding the original func and arg that the wrapper function can then call. Provide an iterator function for the virtual network stack (vnet) that will call the callback function for each network stack. Provide a new set of macros for VNET that in the non-VIMAGE case will just call eventhandler_register() while in the VIMAGE case it will use vimage_eventhandler_register() passing in the extra iterator function but will only register once rather than per-vnet. We need a special macro in case we are interested in the tag returned as we must check for curvnet and can neither simply assign the return value, nor not change it in the non-vnet0 case without that. Sponsored by: ISPsystem Discussed with: jhb Reviewed by: zec (earlier version), jhb MFC after: 1 month
2010-03-19 19:51:03 +00:00
#endif
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
void
eventhandler_deregister(struct eventhandler_list *list, eventhandler_tag tag)
{
struct eventhandler_entry *ep = tag;
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
EHL_LOCK_ASSERT(list, MA_OWNED);
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
if (ep != NULL) {
/* remove just this entry */
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
if (list->el_runcount == 0) {
CTR3(KTR_EVH, "%s: removing item %p from \"%s\"", __func__, ep,
list->el_name);
TAILQ_REMOVE(&list->el_entries, ep, ee_link);
free(ep, M_EVENTHANDLER);
} else {
CTR3(KTR_EVH, "%s: marking item %p from \"%s\" as dead", __func__,
ep, list->el_name);
ep->ee_priority = EHE_DEAD_PRIORITY;
}
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
} else {
/* remove entire list */
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
if (list->el_runcount == 0) {
CTR2(KTR_EVH, "%s: removing all items from \"%s\"", __func__,
list->el_name);
while (!TAILQ_EMPTY(&list->el_entries)) {
ep = TAILQ_FIRST(&list->el_entries);
TAILQ_REMOVE(&list->el_entries, ep, ee_link);
free(ep, M_EVENTHANDLER);
}
} else {
CTR2(KTR_EVH, "%s: marking all items from \"%s\" as dead",
__func__, list->el_name);
TAILQ_FOREACH(ep, &list->el_entries, ee_link)
ep->ee_priority = EHE_DEAD_PRIORITY;
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
}
}
If the runcount is non-zero in eventhandler_deregister() then one or more threads are executing the eventhandler, sleep in this case to make it safe for module unload. If the runcount was up then an entry would have been marked EHE_DEAD_PRIORITY so use this as a trigger to do the wakeup in eventhandler_prune_list(). Reviewed by: jhb
2009-12-17 21:17:13 +00:00
while (list->el_runcount > 0)
mtx_sleep(list, &list->el_lock, 0, "evhrm", 0);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
EHL_UNLOCK(list);
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
}
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
/*
* Internal version for use when eventhandler list is already locked.
*/
static struct eventhandler_list *
Use 'const char *' for a few prototypes. Reviewed by: ru
2004-12-06 10:53:40 +00:00
_eventhandler_find_list(const char *name)
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
{
struct eventhandler_list *list;
mtx_assert(&eventhandler_mutex, MA_OWNED);
TAILQ_FOREACH(list, &eventhandler_lists, el_link) {
if (!strcmp(name, list->el_name))
break;
}
return (list);
}
/*
* Lookup a "slow" list by name. Returns with the list locked.
*/
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
struct eventhandler_list *
Use 'const char *' for a few prototypes. Reviewed by: ru
2004-12-06 10:53:40 +00:00
eventhandler_find_list(const char *name)
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
{
struct eventhandler_list *list;
Don't try to find an eventhandler list if the list of lists hasn't been initialized yet.
2001-07-31 03:52:16 +00:00
if (!eventhandler_lists_initted)
return(NULL);
Make the EVENTHANDLER mechanism MP-safe. Events can now be invoked without holding the Giant lock.
2000-09-22 03:17:35 +00:00
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
/* scan looking for the requested list */
Change and clean the mutex lock interface. mtx_enter(lock, type) becomes: mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks) mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized) similarily, for releasing a lock, we now have: mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN. We change the caller interface for the two different types of locks because the semantics are entirely different for each case, and this makes it explicitly clear and, at the same time, it rids us of the extra `type' argument. The enter->lock and exit->unlock change has been made with the idea that we're "locking data" and not "entering locked code" in mind. Further, remove all additional "flags" previously passed to the lock acquire/release routines with the exception of two: MTX_QUIET and MTX_NOSWITCH The functionality of these flags is preserved and they can be passed to the lock/unlock routines by calling the corresponding wrappers: mtx_{lock, unlock}_flags(lock, flag(s)) and mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN locks, respectively. Re-inline some lock acq/rel code; in the sleep lock case, we only inline the _obtain_lock()s in order to ensure that the inlined code fits into a cache line. In the spin lock case, we inline recursion and actually only perform a function call if we need to spin. This change has been made with the idea that we generally tend to avoid spin locks and that also the spin locks that we do have and are heavily used (i.e. sched_lock) do recurse, and therefore in an effort to reduce function call overhead for some architectures (such as alpha), we inline recursion for this case. Create a new malloc type for the witness code and retire from using the M_DEV type. The new type is called M_WITNESS and is only declared if WITNESS is enabled. Begin cleaning up some machdep/mutex.h code - specifically updated the "optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently need those. Finally, caught up to the interface changes in all sys code. Contributors: jake, jhb, jasone (in no particular order)
2001-02-09 06:11:45 +00:00
mtx_lock(&eventhandler_mutex);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
list = _eventhandler_find_list(name);
if (list != NULL)
EHL_LOCK(list);
Change and clean the mutex lock interface. mtx_enter(lock, type) becomes: mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks) mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized) similarily, for releasing a lock, we now have: mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN. We change the caller interface for the two different types of locks because the semantics are entirely different for each case, and this makes it explicitly clear and, at the same time, it rids us of the extra `type' argument. The enter->lock and exit->unlock change has been made with the idea that we're "locking data" and not "entering locked code" in mind. Further, remove all additional "flags" previously passed to the lock acquire/release routines with the exception of two: MTX_QUIET and MTX_NOSWITCH The functionality of these flags is preserved and they can be passed to the lock/unlock routines by calling the corresponding wrappers: mtx_{lock, unlock}_flags(lock, flag(s)) and mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN locks, respectively. Re-inline some lock acq/rel code; in the sleep lock case, we only inline the _obtain_lock()s in order to ensure that the inlined code fits into a cache line. In the spin lock case, we inline recursion and actually only perform a function call if we need to spin. This change has been made with the idea that we generally tend to avoid spin locks and that also the spin locks that we do have and are heavily used (i.e. sched_lock) do recurse, and therefore in an effort to reduce function call overhead for some architectures (such as alpha), we inline recursion for this case. Create a new malloc type for the witness code and retire from using the M_DEV type. The new type is called M_WITNESS and is only declared if WITNESS is enabled. Begin cleaning up some machdep/mutex.h code - specifically updated the "optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently need those. Finally, caught up to the interface changes in all sys code. Contributors: jake, jhb, jasone (in no particular order)
2001-02-09 06:11:45 +00:00
mtx_unlock(&eventhandler_mutex);
Make the EVENTHANDLER mechanism MP-safe. Events can now be invoked without holding the Giant lock.
2000-09-22 03:17:35 +00:00
Implement a new generic mechanism for attaching handler functions to events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
1999-08-21 06:24:40 +00:00
return(list);
}
Make the EVENTHANDLER mechanism MP-safe. Events can now be invoked without holding the Giant lock.
2000-09-22 03:17:35 +00:00
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
/*
* Prune "dead" entries from an eventhandler list.
*/
void
eventhandler_prune_list(struct eventhandler_list *list)
{
struct eventhandler_entry *ep, *en;
If the runcount is non-zero in eventhandler_deregister() then one or more threads are executing the eventhandler, sleep in this case to make it safe for module unload. If the runcount was up then an entry would have been marked EHE_DEAD_PRIORITY so use this as a trigger to do the wakeup in eventhandler_prune_list(). Reviewed by: jhb
2009-12-17 21:17:13 +00:00
int pruned = 0;
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
CTR2(KTR_EVH, "%s: pruning list \"%s\"", __func__, list->el_name);
EHL_LOCK_ASSERT(list, MA_OWNED);
If the runcount is non-zero in eventhandler_deregister() then one or more threads are executing the eventhandler, sleep in this case to make it safe for module unload. If the runcount was up then an entry would have been marked EHE_DEAD_PRIORITY so use this as a trigger to do the wakeup in eventhandler_prune_list(). Reviewed by: jhb
2009-12-17 21:17:13 +00:00
TAILQ_FOREACH_SAFE(ep, &list->el_entries, ee_link, en) {
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
if (ep->ee_priority == EHE_DEAD_PRIORITY) {
TAILQ_REMOVE(&list->el_entries, ep, ee_link);
free(ep, M_EVENTHANDLER);
If the runcount is non-zero in eventhandler_deregister() then one or more threads are executing the eventhandler, sleep in this case to make it safe for module unload. If the runcount was up then an entry would have been marked EHE_DEAD_PRIORITY so use this as a trigger to do the wakeup in eventhandler_prune_list(). Reviewed by: jhb
2009-12-17 21:17:13 +00:00
pruned++;
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
}
}
If the runcount is non-zero in eventhandler_deregister() then one or more threads are executing the eventhandler, sleep in this case to make it safe for module unload. If the runcount was up then an entry would have been marked EHE_DEAD_PRIORITY so use this as a trigger to do the wakeup in eventhandler_prune_list(). Reviewed by: jhb
2009-12-17 21:17:13 +00:00
if (pruned > 0)
wakeup(list);
Rework the eventhandler locking for hopefully the last time. The scheme used popped into my head during my morning commute a few weeks ago, but it is also very similar (though a bit simpler) to a patch that mini@ developed a while ago. Basically, each eventhandler list has a mutex and a run count. During an eventhandler invocation, the mutex is held while we traverse the list but is dropped while we execute actual handlers. Also, a runcount counter is incremented at the start of an invocation and decremented at the end of an invocation. Adding to the list is not a big deal since the reference of a thread currently executing the handlers remains valid across an add operation. Whether or not new handlers are executed by threads currently executing the handlers for a given list is indeterminate however. The harder case is when a handler is removed from the list. If the runcount is zero, the handler is simply removed from the list directly. If the runcount is not zero, then another thread is currently executing the handlers of this list, so the priority of this handler is set to a magic value (currently -1) to mark it as dead. Dead handlers are not executed during an invocation. If the runcount is zero after it is decremented at the end of an invocation, then a new eventhandler_prune_list() function is called to remove dead handlers from the list. Additional minor notes: - All the common parts of EVENTHANDLER_INVOKE() and EVENTHANDLER_FAST_INVOKE() have been merged into a common _EVENTHANDLER_INVOKE() macro to reduce duplication and ease maintenance. - KTR logging for eventhandlers is now available via the KTR_EVH mask. - The global eventhander_mutex is no longer recursive. Tested by: scottl (SMP i386)
2003-03-11 20:17:00 +00:00
}
Reference in New Issue Copy Permalink