On Fri, Feb 17, 2023 at 04:55:27PM +0100, Christian König wrote: > Am 17.02.23 um 13:37 schrieb Jani Nikula: > > On Fri, 17 Feb 2023, Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote: > > > If i915 have such structural problems then I strongly suggest to solve > > > them inside i915 and not make common code out of that. > > All other things aside, that's just a completely unnecessary and > > unhelpful remark. > > Sorry, but why? > > We have gone through the same problems on radeon and it was massively > painful, what I try here is to prevent others from using this bad design as > well. And yes I think devm_ and drmm_ is a bit questionable in that regard > as well. > > The goal is not to make it as simple as possible to write a driver, but > rather as defensive as possible. In other words automatically releasing > memory when an object is destroyed might be helpful, but it isn't > automatically a good idea. > > What can easily happen for example is that you run into use after free > situations on object reference decommissions, e.g. parent is freed before > child for example. I know that radeon/amd are going different paths on this, but I think it's also very clear that you're not really representing the consensus here. For smaller drivers especially there really isn't anyone arguing against devm/drmm. Similar for uapi interfaces that just do the right thing and prevent races. You're the very first one who argued this is a good thing to have. kernfs/kobj/sysfs people spend endless amounts of engineer on trying to build something that's impossible to get wrong, or at least get as close to that as feasible. I mean the entire rust endeavour flies under that flag too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
