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

On Thu, 27 Feb 2003, Werner Almesberger wrote:

> > There are several module interfaces:
> > - module user interface
> > - module load interface
> > - module driver interface
>
> Hmm, the "load interface" would be the system calls, while
> the "driver interface" would be initialization and cleanup
> functions in the module ?
>
> We've already established that most things called from the
> latter isn't actually module specific.

But the module driver interface has an impact on the other driver
interfaces and that's what I tried to describe in the previous mail.

> > These are quite independent and so far we were talking about the last one,
> > so I'm a bit confused about your request to talk about the first.
>
> I'm not so sure about them being independent. E.g. if we
> just had a blocking single-phase cleanup, users would always
> see success, but resources may be tied up indefinitely, which
> would break uses like
>
> rmmod foo
> insmod foo.o

rmmod could already fail before, because the module is busy, so I'm not
sure, what should break here.

> On the other hand, with a non-blocking two-phase cleanup, users
> would still always see success, but only "anonymous" resources
> (memory, etc.) would be tied up.
>
> Last but not least, a non-blocking single-phase cleanup would
> expose all failures to the user, and require some retry strategy.

Now you're skipping ahead. You are already looking at the possible
consequences for the module user interface, before we actually made clear
in which ways the module driver interface could be changed.
There are of course dependencies between the interfaces, but you can
change a lot in one before you have to modify another.

> Furthermore, use counts can have several meanings:
> - indicate when it's convenient for the module to be removed
> - indicate when it's possible for the module to be removed
> - indicate what consequences the user may experience if
> trying to remove now (e.g. blocking)
>
> The "old" module count was a bit of a mixture of the first two.
> The "new" count is clearer.

There is/was no count for the first?!
Which "new" count?

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.084 / U:2.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site