On Mon, 29 Mar 2004, Greg KH wrote: > On Mon, Mar 29, 2004 at 03:31:17PM -0800, Andrew Morton wrote: > > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > The module should remain in memory, "unhashed", until the final kobject > > > > reference falls to zero. Destruction of that kobject causes the refcount > > > > on the module to fall to zero which causes the entire module to be > > > > released. > > > > > > > > (hmm, the existence of a kobject doesn't appear to contribute to its > > > > module's refcount. Why not?) > > > > > > It does, if a file for that kobject is opened. In this case, there was > > > no file opened, so the module refcount isn't incremented. > > > > hm, surprised. Shouldn't the existence of a kobject contribute to its > > module's refcount? > > No, a kobject by itself knows nothing about a module. Only the > attribute files do (and they are the things that contain the struct > module *), as they are what user space can grab references to.
There's another reason. Practically every module has kobjects registered all the time; they are not unregistered until the module's unload procedure runs. If these kobjects contributed to the modules refcount then it would be impossible ever to rmmod the module without using the -f flag. Furthermore, all the excess usage counts from those kobjects would swamp and hide the genuine usage counts (the ones that are displayed now). The user would have no way to know whether rmmod -f would work or would hang. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
