On Wed, 2022-06-01 at 10:33 +0000, Dmitry Rokosov wrote: > Hi Nuno, > > Thank you for comments! > > On Wed, Jun 01, 2022 at 10:47:54AM +0200, Nuno Sá wrote: > > On Tue, 2022-05-31 at 18:57 +0000, Dmitry Rokosov wrote: > > > Hi Jonathan, > > > > > > I have one question about a cases when trigger owner is builtin > > > module. > > > In the such cases trig->owner == null, because THIS_MODULE equals > > > to > > > null. How do you think, should we take into account such > > > situations? > > > > > > IMHO we have to take in and save this information to trig_info > > > during > > > trigger allocation call. For example we can check THIS_MODULE > > > from > > > the > > > > Hmmm, If we were to do something during iio_trigger_alloc(), we > > would > > rather assign already THIS_MODULE to owner and we would not need > > this > > WARN(). I mean, if someone calls iio_trigger_get() before > > allocating > > it, it will have bigger problems :). > > > > You are right, non-allocated pointer dereference is much bigger > problem :) > > > I think this could actually be something reasonable... > > I think it could be a good solution, but it's required a lot of > changes > in the IIO drivers code, because if we assign trig->owner from > iio_trigger_alloc(), we do not need this_mod parameter in the > iio_trigger_register() iface and its wrappers. > So it means to make it workable we must: > - rework iio_trigger_alloc() > - redesign iio_trigger_register() iface and its wrappers > - correct iio_trigger_register() call from all IIO drivers > > I suppose we need to wait for Jonathan's comments here... > I think we could actually get this done without having to change all the drivers. Note on how iio_trigger_register() passes THIS_MODULE to the internal API. We could also use macros in the alloc function in a way that only internal functions would need to be changed. But it all depends on whether or not Jonathan wants this moved... - Nuno Sá
