lkml.org 
[lkml]   [2013]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] module, async: async_synchronize_full() on module init iff async is used
    On Tue, Jan 15, 2013 at 7:25 PM, Tejun Heo <tj@kernel.org> 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


    \
     
     \ /
      Last update: 2013-01-16 05:21    [W:2.765 / U:0.508 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site