Re: [RFC] new module format

Roman Zippel (zippel@linux-m68k.org)
Thu, 18 Jul 2002 00:45:20 +0200 (CEST)


Hi,

On Wed, 17 Jul 2002, Daniel Phillips wrote:

> > The start/stop methods are not needed to fix the races, they allow better
> > control of the unload process.
>
> I'm afraid it must show that I didn't read the previous threads closely
> enough, but what is the specific benefit supposed to be, if not to address
> the races?

The basic idea is to allow modules to let the unload fail. The unload
process would basically look like this:

unregister all interfaces;
if (no users)
free all resources;

These two phases have to be done anyway, making it explicit in the module
interface gives more control to the user, e.g. you can disallow the
mounting of a new fs, while others are still mounted.

> > For filesystems it's only simpler because they only have a single entry
> > point, but the basic problem is always the same.
>
> What do you mean by single entry point? Mount? Register_filesystem?

I meant the first entry point into the module code that needs to be
protected (e.g. get_sb during mount).

> So, I'm still hoping to hear a substantive reason why the filesystem model
> can't be applied in general to all forms of modular code.

It's possible to use the filesystem model, but it's unnecessary complex
and inflexible. It should be possible to keep try_inc_mod_count() out of
the hot paths, but you have to call it e.g. at every single open().
Another problem is that the more interfaces a module has (e.g. proc), the
harder it becomes to unload a module (or the easier it becomes to prevent
the unloading of a module).

> To remind you
> of the issue: the proposition is that the subsystem in the module is
> always capable of knowing when the module is quiescent, because it does
> whatever is necessary to keep track of the users and what they're doing.

The problem is that the module can't do anything with that information, at
the time cleanup_module() is called it's already to late. That information
has currently to be managed completely outside of the module.

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/