On Thu, Sep 30, 2010 at 11:04:16PM -0700, Andrew Morton wrote: > No, we've run into problems *frequently*. A common case is where we > convert a mutex to a spinlock or vice versa. If you don't rename the > lock, the code still compiles (with warnings) and crashes horridly at > runtime. Sorry, if you run code with that obvious warnings you beg for trouble. If you really believe your advanced users arw too stupid to read compiler warnings enforcing -Werror is for sure better than obsfucating the code. > Still wrong. We do this frequently and we do it in areas where we > believe that the implementation might change in the future. > > Had we done it with i_count from day one then this part of the patchset > would be far simpler. I don't thin that's quite true. The big point of using i_lock is that we can hold it over accessing other things that also are protected by it. No accessor is going to help you with that. For plain opencoded increments we indeed need a helper as shown by Chris' aio speedup and the churn in here - but that's already added later in the series and I asked Dave to move it before this patch. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
