Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Atomic context and kernel API design
Atomic context and kernel API design
Posted Mar 25, 2008 18:00 UTC (Tue) by im14u2c (subscriber, #5246)Parent article: Atomic context and kernel API design
Hmm... if in_atomic only has one or two narrow, valid uses, perhaps it shouldn't be a macro at all? Either a small, static function in the one source file that uses it? GCC will still inline it, but the static declaration would send the signal "not for outside consumption."
(Log in to post comments)
Atomic context and kernel API design
Posted Mar 25, 2008 19:04 UTC (Tue) by epa (subscriber, #39769) [Link]
Indeed, you might ask why use macros at all for this kind of thing, when compiler-inlined functions are just as efficient?
Atomic context and kernel API design
Posted Mar 25, 2008 19:40 UTC (Tue) by IkeTo (subscriber, #2122) [Link]
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 im14u2c (subscriber, #5246) [Link]
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.
Atomic context and kernel API design
Posted Mar 25, 2008 22:51 UTC (Tue) by jd (subscriber, #26381) [Link]
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.
Atomic context and kernel API design
Posted Mar 25, 2008 23:54 UTC (Tue) by im14u2c (subscriber, #5246) [Link]
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.