On Thu, 26 Apr 2007, Cornelia Huck wrote: > On Wed, 25 Apr 2007 16:13:12 -0400 (EDT), > Alan Stern <[EMAIL PROTECTED]> 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.
Good. > > > 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. Yes. However if the driver forgets to clear the field it shouldn't cause a warning. After all, there won't be any harm; the next driver to bind to the device will just overwrite the driver_data anyway. > > 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). I agree. > > > > 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. No, no! The "gone" flag must be in the private data structure. If it were in a container of the device structure, then it could be overwritten when a different driver binds to the device. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
