Hi,
On Fri, 14 Feb 2003, Werner Almesberger wrote:
> > Yes, and now compare how the solutions differ when the data is static and
> > when it's allocated.
>
> Do they ? Even if the data is static, it can become invalid
> (in the sense that accessing it from a callback would lead
> to some kind of undesirable behaviour, even though the access
> itself would work), so I don't quite see why the difference
> would matter.
Let's stay at the main problem, we have find out when it's safe to delete
an object. For dynamic objects you have the following options:
- callbacks: when the refcount becomes zero, we call a function to remove
the object.
- failure: we just return -EBUSY and try again later.
- wait: we simply wait until the refcount becomes zero
Static objects and functions are freed by the module code and usually we
want to unregister them at module unload time, so there are basically two
ways:
- we use the module count via try_module_get/module_put
- we use your own refcount and must wait in module_exit until all users
are gone
If we exclude the possibly-wait-forever-option, do you see the problem
for dynamic objects which also contain references to static data/
functions? Procfs entries are such objects, there is a count field for the
dynamic part and an owner field for the static part and proc_get_inode
always has to get two references. The interesting question is now, can we
get rid of one of them?
If the answer is no, it would mean we need two procfs APIs, one which can
be used from module_exit and another which can be used to remove dynamic
entries. OTOH if we want to avoid this it would mean we have to make one
or more of the above options generically usable.
I stop here, because before we can discuss possible solutions, we have to
agree, that this problem is real.
Rusty, did I make any mistake so far? I'd really like to have your opinion
too. You are free to flame me, if I made any mistake, but please do it
with a bit more substance than just accusing me of ignorance.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:01:05 EST