From: Andrew Morton <akpm@linux-foundation.org>
To: Pravin Shedge <pravin.shedge4linux@gmail.com>
Cc: fkostenzer@live.at, andriy.shevchenko@linux.intel.com,
geert@linux-m68k.org, paul.gortmaker@windriver.com,
linux-kernel@vger.kernel.org, Jessica Yu <jeyu@kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH] lib: add module unload support to sort tests
Date: Tue, 19 Dec 2017 14:51:36 -0800 [thread overview]
Message-ID: <20171219145136.e50d3b4c71fc4b9b6de50338@linux-foundation.org> (raw)
In-Reply-To: <CALSsfODvGLKTMitvyypWwVHXtqtdNYg3JSJNFuwf+g78Ciimkw@mail.gmail.com>
On Tue, 19 Dec 2017 23:10:00 +0530 Pravin Shedge <pravin.shedge4linux@gmail.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?
next prev parent reply other threads:[~2017-12-19 22:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-17 9:49 Pravin Shedge
2017-12-18 22:21 ` Andrew Morton
2017-12-19 17:40 ` Pravin Shedge
2017-12-19 22:51 ` Andrew Morton [this message]
2017-12-19 23:06 ` Randy Dunlap
2017-12-20 4:13 ` Paul Gortmaker
2017-12-21 2:05 ` Pravin Shedge
2017-12-22 18:25 ` [PATCH v2] " Pravin Shedge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171219145136.e50d3b4c71fc4b9b6de50338@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=fkostenzer@live.at \
--cc=geert@linux-m68k.org \
--cc=jeyu@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=pravin.shedge4linux@gmail.com \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome