On Wed, Feb 17, 2010 at 2:41 PM, Mike Frysinger <vapier....@gmail.com> wrote: > On Wed, Feb 17, 2010 at 16:07, Grant Likely wrote: >> Also, even if I agreed with the premise that a cookie is needed for >> deciding who can use the bus when locked, it is still a good idea to >> use a different API when working with a locked bus. Locking issues >> are subtle, and driver authors *must understand what they are doing*. >> Using a different API for talking to a locked bus is one of the things >> that makes absolute sense to make sure that drivers know which regions >> have the bus locked, and which do not. > > these sort of statements are always made yet it doesnt seem to prevent > bugs. of course people *should know what they're doing*, but > *reality* is that people make mistakes and bugs get merged all the > time. a little proactive protection goes a long way. i dont think > adding a cookie would increase overhead all that much.
Heh. Alright. Then I think I'd like to see a follow-on patch that adds the cookie checking so that it can be reviewed independently of all the locking additions. Cheers, g. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general