Atomic context and kernel API design

Atomic context and kernel API design

Posted Mar 25, 2008 22:51 UTC (Tue) by jd (guest, #26381)
In reply to: Atomic context and kernel API design by jzbiciak
Parent article: Atomic context and kernel API design

Perhaps instead of changing the name, change the macro so that it means what it says at all levels. Different calling files set a different value to some symbol, which indicates to the header which type of atomic context you're thinking about.

Then all you need do is ensure that (a) there's a way to know whether the context is atomic or not, and (b) the same method is used across that file and across any includes that may be brought in by that file.

Alternatively, you could have two parallel kernels, one always atomic, the other always not. Then you'd never need to test at all. Although you would have the communications problem from hell that all parallel solutions suffer from.

---

to post comments

If you follow Andrew Morton's reasoning, "am I in atomic" is something a caller should never
ask.  It should be told explicitly, as in the case of kmalloc().

The case where "in_atomic" is getting used "legitimately" is in a fault handler (which should
not be a fastpath pretty much by definition).  It sounds like they're abusing preempt_count to
coax a particular behavior out of the fault handler, rather than just stating the intended
behavior directly.  That doesn't necessarily sound like clean design to me, but rather an
overly clever hack.

I'm sure someone more familiar with this mechanism can explain why it is or is not a good
mechanism.