[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171219145136.e50d3b4c71fc4b9b6de50338@linux-foundation.org>
Date: Tue, 19 Dec 2017 14:51:36 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Pravin Shedge <pravin.shedge4linux@...il.com>
Cc: fkostenzer@...e.at, andriy.shevchenko@...ux.intel.com,
geert@...ux-m68k.org, paul.gortmaker@...driver.com,
linux-kernel@...r.kernel.org, Jessica Yu <jeyu@...nel.org>,
Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH] lib: add module unload support to sort tests
On Tue, 19 Dec 2017 23:10:00 +0530 Pravin Shedge <pravin.shedge4linux@...il.com> wrote:
> >
> > If so, why do you think we shiould alter lib/test_sort.c to behave in
> > this atypical fashion?
>
> If test case is going affects only at boot time or at module load
> time, it's smart decision to unload module
> automatically on successful completion.
OK.
I think it does make sense for a lib/text_*.ko type module to unload
itself after successful completion of the test. However:
- returning a fake error code from the module's module_init() is a
daft way of doing that. We should find a way to let the
module_init() handler tell do_init_module() "I succeeded, but please
unload me anyway". So the initial sys_init_module() call doesn't say
"it failed". Could create a new, kernel-internal errno for this and
have do_init_module() rewrite that to 0.
Maybe. A sys_init_module() caller's expectation is that if the
syscall succeeded then the module is now loaded.
Well. Except for the test_*.ko modules, which are special.
- Changing any test module so that it now auto-unloads on success is
a non-back-compat change. The practical effect of which will be very
minor: a subsequent rmmod finds that the module isn't there.
I'm not sure what to do, really. Does any of this matter much at all?
Powered by blists - more mailing lists