Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Perhaps that "one or two narrow, valid uses" are in different files?
Atomic context and kernel API design
Posted Mar 25, 2008 19:59 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246)
Hmmm... it looks like something to be called by a "per-arch" files, so even "one use" actually
lives in multiple files. :-)
I guess it belongs in a header, but I still wonder if it shouldn't have a different name.
Posted Mar 25, 2008 22:51 UTC (Tue) by jd (guest, #26381)
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.
Posted Mar 25, 2008 23:54 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246)
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
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds