Re: [PATCH] module, async: async_synchronize_full() on module initiff async is used

[Linus Torvalds]

On Tue, Jan 15, 2013 at 7:25 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> Hello, Linus.
>
> On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
>> That said, maybe we could just make the rule be that you can't pick a
>> default IO scheduler that is modular.
>
> This is definitely much more preferable but it would affect use case
> where everything is built modular and the elevator is selected via
> kernel param.  This is way outside the usual usage and we can warn
> about the new behavior but it still is an observable behavior change.
> Do you think this would be okay?

I do want the same user-visible semantics, so it's not some one-liner.

The compiled-in elevator would be easy enough to handle in the Kconfig
file (maybe we do already, I didn't even bother to check). The real
problem is the "chosen_elevator" one, which is dynamic with the kernel
command line. And we could handle that one by just trying to load the
module early (but exactly _when_?) and then instead of looking things
up by name, just keep a pointer to the default elevator around.

But no, it's not just some trivial one-liner. Especially the question
about "when to try to load the module that is given on the kernel
command line" is not trivial. Do we require that the module is in the
initrd and loadable basically immediate at boot? Do we try again after
switching the root filesystem? Things like that..

> And then this warning can be added without introducing
> request_module_but_dont_warn_about_being_called_from_async().

I do agree that it would be much nicer that way.

               Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/