![]() | |||||||||||||
Messages in this thread |
> Even if ARM is able to handle any arbitrary C code between the > "load locked" and store conditional API, other architectures can not > by definition. Maybe so, but I think you and Linus are missing the middle ground. While I agree that LL/SC can't be part of the kernel API for people to get arbitrarily clever with in the device driver du jour, they are *very* nice abstractions for shrinking the arch-specific code size. The semantics are widely enough shared that it's quite possible in practice to write a good set of atomic primitives in terms of LL/SC and then let most architectures define LL/SC and simply #include the generic atomic op implementations. If there's a restriction that would pessimize the generic implementation, that function can be implemented specially for that arch. Then implementing things like backoff on contention can involve writing a whole lot less duplicated code. Just like you can write a set of helpers for, say, CPUs with physically addressed caches, even though the "real" API has to be able to handle the virtually addressed ones, you can write a nice set of helpers for machines with sane LL/SC. - 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/ | ||||||||||||
| Last update: 2006-12-11 02:33 [from the cache] ©2003-2008 | |||||||||||||