Re: [RFC] add kobject to struct module

[Patrick Mochel]

> > read/write of what?  The attribute?  Sure, why not set the module
> > attribute sysfs file to the module that way the reference count will be
> > incremented if the sysfs file is opened.
> 
> Hmm, because there's one attribute: which module would own it?  You're
> going to creation attributes per module later (for module parameters),
> so when you do that it might make sense to do this too.

kernel/module.c owns the attribute code. (The same code and attribute 
structure is reused for each object its exported for, so the owner field 
must be set to the owner of the code itself.) 

> > But in looking at your patch, I don't see why you want to separate the
> > module from the kobject?  What benefit does it have?
> 
> The lifetimes are separate, each controlled by their own reference
> count.  I *know* this will work even if someone holds a reference to
> the kobject (for some reason in the future) even as the module is
> removed.

Correct me if I'm wrong, but this sounds similar to the networking 
refcount problem. The reference on the containing object is the 
interesting one, as far as visibility goes. As long as its positive, the 
module is active. 

The kobject refcount can still be used for the lifetime of the object. It
can simply be pinned the entire time the module is active. When the module
is deleted, the kobject can be unregistered somewhere around
free_module(). It looks like you might want to split that up into two
parts: "Before unregistering the kobject" that removed it from lists, etc, 
and "In kobject release method", which would call module_free() (and 
probably free the args then too). 

This way you should retain the same semantics and be able to use the 
kobject for controlling the lifetime (which will allow you to safely 
export attributes through sysfs). 

Make sense? 


	Pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/