| |||||||||||||
Reworking the semaphore interfaceReworking the semaphore interfacePosted Dec 15, 2005 15:08 UTC (Thu) by jreiser (subscriber, #11027)Parent article: Reworking the semaphore interface
The improved clarity of identifying mutual exclusion [only] is welcome. However, a flag day (when the old usage no longer works at all) is painful. Could there be a compile-time option CONFIG_KMUTEX_USES_KSEMAPHORE which preserves source compatibility, perhaps even binary compatibility?
(Log in to post comments)
Reworking the semaphore interface Posted Dec 15, 2005 22:02 UTC (Thu) by khim (subscriber, #9252) [Link] Could there be a compile-time option CONFIG_KMUTEX_USES_KSEMAPHORE which preserves source compatibility, perhaps even binary compatibility? Binary compatibility is not even considered (as usual), source compatibility is discussed.
Reworking the semaphore interface Posted Dec 18, 2005 9:14 UTC (Sun) by hamjudo (subscriber, #363) [Link] As a very occasional kernel hacker who mostly codes by looking at other device drivers. If I model my code after obsolete code or documentation, I don't want source code compatibility. I want a compile time error message that is easy to google.If there is a flag day, could someone do people like me a favor? Attempt to compile a function written in the old style, with headers for the new style, then paste the error message into a comment attached to this article. Or if the details change, the article describing the updated change. If I forget about this change when it matters and I make the mistake, google will lead me to an article that tells me the right way to do it.
|
|||||||||||||