User: Password:
|
|
Subscribe / Log in / New account

Atomic context and kernel API design

Atomic context and kernel API design

Posted Mar 25, 2008 19:40 UTC (Tue) by IkeTo (subscriber, #2122)
In reply to: Atomic context and kernel API design by jzbiciak
Parent article: Atomic context and kernel API design

Perhaps that "one or two narrow, valid uses" are in different files?


(Log in to post comments)

Atomic context and kernel API design

Posted Mar 25, 2008 19:59 UTC (Tue) by jzbiciak (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 (guest, #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 jzbiciak (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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds