[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46EE68AC.3090809@Free.fr>
Date: Mon, 17 Sep 2007 13:44:44 +0200
From: Eric Valette <Eric.Valette@...e.fr>
To: Johannes Berg <johannes@...solutions.net>
CC: "??????? <\"Paul Rolland \"" <rol@...be.net>,
Rob Hussey <robjhussey@...il.com>, flamingice@...rmilk.net,
andreamrl@...cali.it, linux-kernel@...r.kernel.org
Subject: Re: rtl8187 driver in 2.6.23-rc6-git5: kernel panic if not used as
a module. Works as a module.
Johannes Berg wrote:
> On Sa, 2007-09-15 at 21:00 +0200, Eric Valette wrote:
>
>
>> I came to this conclusion too. But I would have preferred to have
>> #define subsys_exit(fn) modules_exit(fn)
>>
>> in the case of a module and nop in the non module case...
>>
>
> module_exit is a no-op anyway in the non-modular case, it's never
> called, so what's the point?
>
That I would have prefered to see subsys_exit in front of
subsys_initcall instead of module_exit because
1) it made me wonder if it still works in the module case
2) If you see the comment in init.h (/* Don't use these in modules,
but some people do... */), you should not use it in module. The comment
is, at least misleading, because for code that can be used as module or
directly embedded in some cases you are indeed forced to use it (did a
grep and found a lot)
3) Non symetrical code frequently points to errors or bad design.
YMMV :-)
4) If someone someday find something to do when shutting down
(hotrestart, fault tolerance, or something equivalent), we would have a
place to hook. C++ has destructors called after main and before __exit...
NB : This has nothing to do with the proposed patch that is definitively
correct given current init.h.
Personally, I would certainly add:
#define subsys_exit(fn) in init.h
But would rate it myself as a cosmetic change as it *only* makes the code more obvious to read :-)
-- eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists