[lkml]   [2002]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] new module format

On Thu, 18 Jul 2002, Daniel Phillips wrote:

> But I don't see why this needs to be a two step process:
> module support calls mod->cleanup
> module code checks number of users
> if none, unregister all interfaces
> otherwise return -EBUSY
> if return wasn't -EBUSY, free all resources

So after you checked for users, someone starts using the module again,
before you were able to remove all interfaces -> OOPS.
This is exactly the reason why I prefer to make this explicit in the
module interface - the chances are higher to get this right.

> > It's possible to use the filesystem model, but it's unnecessary complex
> > and inflexible.
> What is the complex and inflexible part?

It has to work around the problem that cleanup_module() can't fail.

> > 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).
> I don't see that this makes any difference at all.

It's currently impossible to force the unloading of a module, some user
can always keep a reference to the module. Even if you kill the process,
someone else can get a new reference, before you could unload the module.

> I'm proposing to add a return code to mod->cleanup (and pick a better
> name). Yes, every module will have to be fixed to use this interface, but
> why not?

I don't disagree, but if we break the module interface anyway, why don't
we clean it up properly?
(Patches that do that will follow shortly.)

> Anyway, you're proposing to do it backwards. We need to first ensure
> there are no users, then unregister the interfaces.

That's broken (see above).

bye, Roman

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.040 / U:11.836 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site