lkml.org 
[lkml]   [2003]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[RFC] Is an alternative module interface needed/possible?
Hi,

(Subject changed to hopefully get a bit more attention.)

On Mon, 17 Feb 2003, Werner Almesberger wrote:

> > If we exclude the possibly-wait-forever-option, do you see the problem
> > for dynamic objects which also contain references to static data/
> > functions?
>
> You mean that two locking mechanisms are used, where one of them
> shouldn't be doing all that much ? Well, yes.
>
> Now, is this a problem, or just a symptom ? I'd say it's a symptom:
> we already have a perfectly good locking/synchronization method,
> and that's through the register/unregister interface, so the
> module-specific part is unnecessary.

If it was perfectly good, we hadn't a problem. :)

> That much about the theory. Of course, in real life, we have to
> face a few more problems:
>
> - if callbacks can happen after apparently successful "unregister",
> we die
> - if accesses to other static data owned by a module can happen
> after apparently successful "unregister", we may die
> - if a module doesn't "unregister" at all, we die too
>
> But all these problems equally affect code that does other things
> that can break a callback/access, e.g. if we destroy *de->data
> immediately after remove_proc_entry returns.
>
> So this is not a module-specific problem.

You're skipping ahead. You haven't solved the problem yet, but you're
already jumping to conclusions. :-)
Remember, that we want to savely remove a proc entry and as added bonus,
we only want a single reference count. Let's look first at the possible
solutions:
module count: by design this only works for entries, which are removed
during module exit, but not for dynamic entries.
failure: if the object is still busy, we just return -EBUSY. This is
simple, but this doesn't work for modules, since during module exit you
can't fail anymore.
callbacks: the callback function itself had to be protected somehow, so
just to unregister a proc entry, you have to register a callback. To
unregister that callback, it would be silly to use another callback and
failure doesn't work with modules, so that only leaves the module count.

The last solution sounds complicated, but exactly this is done for
filesystems and we didn't really get rid of the second reference count, we
just moved it somewhere else, where it hurts least.
Without interface changes this is also the only generic option to export
dynamic data - the drivers have to get a filesystem like interface (or
just become filesystem themselves).

The very basic reason which prevents another solution is that static data
(which includes functions) is controlled by the generic module code and
dynamic data is controlled by the driver itself. It's obvious that we
can't give the module code control over dynamic data, on the other hand
would it be possible to give the driver control over the static data? This
way it suddenly it becomes a module-specific problem - how can we give
drivers more control over its data?

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/

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