On Mon, 13 Mar 2017, Jonathan Cameron wrote: > On 13/03/17 20:40, Julia Lawall wrote: > >>> I like the automated editing because it certainly cuts down on typos, > >>> and even with this one, you can just move the new lock field upon > >>> inspection. Sadly, I don't think the script will apply too widely > >>> because the use of "_state" for driver global data isn't a standard, > >>> nor availability of that struct in the functions needing the locking. > >> I only saw three files that had the mlock and they followed the structure > >> with _state as suffix and only had mutex_lock for &indio_dev->mlock. > >> Hence, I went ahead with the script even though I knew it wasn't probably > >> very safe. > > > > If _state is useful, you can add a regular expression to the metavariable declaration to checkk for that. I think it would be something like: > > > > identifier x =~ "_state$"; > > > > but I don't actually know. I would prefer to use some more semantic > > concept to identify such a structure. For example, structures are often > > stored in other structures or passed to some generic function. Then you > > can get to the structure in a way that is based on its purpose rather than > > its name. > > > > julia > > > This particular one is almost always equal (possibly always) to what comes > from the struct iio_dev a when iio_priv(a) is applied. That seems like a promising lead. An issue with such assignments is that they might occur in a variable declaration or in the rest of the function body. If you write a pattern like the following: @@ struct foo *x; @@ *x = y() then it will match all of: struct foo *a = y(); b = y(); // where b has the right type if ((b = y()) < 0) return; m = b = y(); but not b = m = y(); In this case, you want there to be a path from this initialization to the thing you want to change. And you want to change all occurrences that fit some pattern, so the basic outline would be: *x = y() <... - x + z ...> julia -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
