[lkml]   [2001]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] PART1: Proposed init & module changes for 2.5

I like the PARAM() part, but still have some question. Hope you
can clarify.

On Sun, Sep 23, 2001 at 04:37:43PM +1000, Rusty Russell wrote:
> OLD: module_init(initfn)
> NEW: init_and_startcall(initfn, startfn);
> Please use a semicolon at the end. Modulable code should
> transition to a two-stage init (initfn sets everything up
> and may fail, and startfn which exposes the module to the rest
> of the kernel and can't fail). Some modules only need
> initfn or startfn, in which case use initcall() or startcall().

Why separating them?

> OLD: void exitfn(void) { ...; }
> module_exit(void)
> NEW: int stopfn(void) { ...; return 0; }
> void exitfn(void) { ...; }
> stopcall(stopfn);
> exitcall(exitfn);
> If there are neither, then module is not unloadable. This is
> perfectly OK. If stopfn returns 0 (otherwise it should be
> -errno) it must have deregistered itself from the rest of the
> kernel (ie. module count can never increase again), but still
> be usable to anyone using it currently. Once exitfn is
> called, it is guaranteed to be unused.

Same question here: Why you changed this?

What is meant with "usable to anyone using it currently"?
Does it mean the variables of it can still be read/written?
Can the startcall or the initcall still be called after stopcall?

(Important if we rely on zero initialization, which we do in many

Can IO to ports still be issued and "transactions" still be
finished after stopcall has been issued?

Thanks and Regards

Ingo Oeser
In der Wunschphantasie vieler Mann-Typen [ist die Frau] unsigned und
operatorvertraeglich. --- Dietz Proepper in dasr
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:03    [W:0.042 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site