On Mon, Jul 07, 2025 at 04:18:09PM +0900, Alexandre Courbot wrote: > On Tue Jul 1, 2025 at 7:40 PM JST, Danilo Krummrich wrote: > >> > This makes it inefficient (but not impossible) to access device > >> > resources, e.g. to write device registers, and impossible to call device > >> > methods, which are only accessible under the Core device context. > >> > > >> > In order to solve this, add an additional callback for (1), which we > >> > call unbind(). > >> > > >> > The reason for calling it unbind() is that, unlike remove(), it is *only* > >> > meant to be used to perform teardown operations on the device (1), but > >> > *not* to release resources (2). > >> > >> Ick. I get the idea, but unbind() is going to get confusing fast. > >> Determining what is, and is not, a "resource" is going to be hard over > >> time. In fact, how would you define it? :) > > > > I think the definition is simple: All teardown operations a driver needs a > > &Device<Core> for go into unbind(). > > > > Whereas drop() really only is the destructor of the driver's private data. > > > >> Is "teardown" only allowed to write to resources, but not free them? > > > > "Teardown" is everything that involves interaction with the device when the > > driver is unbound. > > > > However, we can't free things there, that happens in the automatically when the > > destructor of the driver's private data is called, i.e. in drop(). > > Can't we somehow make a (renamed) `unbind` receive full ownership of the > driver's private data, such that it will be freed (and its `drop` > implementation called) before `unbind` returns? Or do we necessarily > need to free that data later? No, we could do that. And I thought about this as well, but I really want to bind the lifetime of the driver's private data stored in a device to the lifetime of this driver being bound to the device. I don't think there is a valid use-case to allow this data as a whole to out-live driver unbind arbitrarily.
