Re: [PATCH RFD] alternative kobject release wait mechanism

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Wed, 25 Apr 2007 16:13:12 -0400 (EDT),
Alan Stern <stern@rowland.harvard.edu> wrote:

> > Documentation/driver-model/lifetime-rules.txt?
> 
> When (if) such a file is added, it should contain more than just these few 
> paragraphs.

This file may be a good idea in general. I'll see if I can come up with
something useful.

> > The remove() method must also unset driver_data.
> 
> It doesn't really have to.  The driver core could do it.

I think it is more consistent if the driver takes care of the fields
specifically designed for its usage.

> It should never need to make that transition.  The only routines in the
> driver which get passed a pointer to the device (as opposed to a pointer
> to the private data) should be the methods called by the driver core or
> sysfs.  Neither will make any calls to the driver after remove() has
> returned, unless the driver does something wrong.

OK, thinko on my side.

> > Uhm. This would imply that a driver may never create a device itself.
> 
> A trivial omission on my part -- "The driver must also retain a module 
> reference to the owner of the device (unless the driver is itself the 
> device's owner)."
> 
> > However, the kobject->owner and module refcounting stuff should remove
> > this restriction.
> 
> If every driver follows this rule, we may not need the kobject->owner 
> stuff.  Although it wouldn't hurt to keep it for safety's sake.

I'm still concerned about that problem. It is that there is simply no
guarantee that everybody released their reference before the module's
exit function returned (the driver itself can and must assure that it
drops its last reference before it finishes exit, but it just can't
control who else holds a reference). I'm much in favour of adding a bit
of code than to risk oopses about which the driver can't do anything
itself (plus, the race exists now, but the immediate disconnect will
involve auditing all drivers).

> > > 		The driver must restrict itself to reading (not
> > > 		writing!) the fields in the device structure.  The
> > > 		only exception is that the driver may lock/unlock
> > > 		dev->sem.
> > 
> > And it may decrease the reference count, of course :)
> 
> :-)  Actually this should be a little more general, since the device will 
> generally be embedded in a larger structure created by the subsystem.  The 
> driver should also be able to acquire and release locks in that larger 
> structure.

Yes. Especially since the "gone"-field may be contained in that
embedding structure if the subsystem controls it.