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. Jonathan -- 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
