> This is an NMI, does it really matter?
Yes. Both for oprofile and the NMI watchdog (which was firing awfully
often last time I checked). The handler needs to be as streamlined as
possible.
> dev_name could be removed, although it would be nice for reporting
> later.
Reporting what ? from where ?
> >Couldn't you modify the notifier code to do the xchg()s (though that's
> >not available on all CPU types ...)
> >
> I don't understand. The xchg()s are for atomicity between the
> request/release code and the NMI handler. How could the notifier code
> do it?
You are using the xchg()s in an attempt to thread onto/off the list
safely no ?
> >>+#define HAVE_NMI_HANDLER 1
> This is so the user code can know if it's available or not.
If we had that for every API or API change, the kernel would be mostly
HAVE_*. It's either available or it's not. If you're maintaining an
external module, then autoconf or similar is the proper way to check for
its existence.
> >Is it not possible to use linux/rcupdate.h for this stuff ?
>
> I'm not sure. It looks possible, but remember, this is an NMI, normal
> rules may not apply. Particularly, you cannot block or spin waiting for
> something else, the NMI code has to run. An NMI can happen at ANY time.
Believe me, I know :)
> If the rcu code can handle this, I could use it, but I have not looked
> to see if it can.
If it's possible (and I have no idea, not having looked at RCU at all)
it seems the right way.
regards
john
-- "Lots of companies would love to be in our hole." - Scott McNealy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/