Re: [RFC] add kobject to struct module

Patrick Mochel
2003-09-10T15:29:29Z

> > 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