On Wed, Jan 18, 2006 at 05:09:10PM -0500, Alan Stern wrote:
> On Wed, 18 Jan 2006, Benjamin LaHaise wrote:
> > The notifier interface is supposed to be *light weight*.
> Again, where is that documented?
Read the kernel. Notifiers are called from all sorts of hot paths, so they
damned well better be light.
> Which is worse: overhead due to cache misses or an oops caused by code
> being called after it was unloaded?
Given that the overhead need not be present at all, neither.
> Do you have a better proposal for a way to prevent blocking notifier
> chains from being modified while in use? Or would you prefer to rewrite
> all the callout routines that currently block, so that all the notifier
> chains can be made atomic and we don't need the blocking notifier API?
Easy: in register_notifier stuff a serial number for each entry put on
a notifier chain. Remember the serial number of the entry before performing
->notifier_call in notifier_call_chain. Upon return, if the chain has been
modified (easy to detect by nature of the serial number changing), walk
the chain looking for the entry following the last serial number run. Voila,
rcu can be used to protect the chain's contents.
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <[email protected]>.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]