-
Patrick Mochel authored
The interface should now be more sane and protect against races better. kobject_register() was split into two helpers: kobject_init() and kobject_add(). It calls both consecutively, though both are also exposed for use by users that want to use the objects w/o adding them to the object hierarchy. kobject_unregister() was made simply a wrapper for kobject_del() and kobject_put(), which are both also exposed. The guts of kobject_put() was moved into kobject_cleanup(), which it calls when the reference count hits 0. (This was done for clarity). The infrastructure now takes a lot in kobject_get() and kobject_put() when checking and modifying the objects' reference counts. This was an obvious one that hsould have been fixed long ago. kobject_add() increments the refcount of the object, which is decremented when kobject_del() is called. This guarantees that the object's memory cannot be freed if it has been added to the hierarchy, and kobject_del() has not been called on it. kobject_init() is now the function that increments the refcount on the object's subsystem, which is decremented only after its release() method has been called for the object in kobject_cleanup(). The documentation has been updated to reflect these changes.
0d3b7ccf