• Petr Mladek's avatar
    kthread: kthread worker API cleanup · 3989144f
    Petr Mladek authored
    A good practice is to prefix the names of functions by the name
    of the subsystem.
    
    The kthread worker API is a mix of classic kthreads and workqueues.  Each
    worker has a dedicated kthread.  It runs a generic function that process
    queued works.  It is implemented as part of the kthread subsystem.
    
    This patch renames the existing kthread worker API to use
    the corresponding name from the workqueues API prefixed by
    kthread_:
    
    __init_kthread_worker()		-> __kthread_init_worker()
    init_kthread_worker()		-> kthread_init_worker()
    init_kthread_work()		-> kthread_init_work()
    insert_kthread_work()		-> kthread_insert_work()
    queue_kthread_work()		-> kthread_queue_work()
    flush_kthread_work()		-> kthread_flush_work()
    flush_kthread_worker()		-> kthread_flush_worker()
    
    Note that the names of DEFINE_KTHREAD_WORK*() macros stay
    as they are. It is common that the "DEFINE_" prefix has
    precedence over the subsystem names.
    
    Note that INIT() macros and init() functions use different
    naming scheme. There is no good solution. There are several
    reasons for this solution:
    
      + "init" in the function names stands for the verb "initialize"
        aka "initialize worker". While "INIT" in the macro names
        stands for the noun "INITIALIZER" aka "worker initializer".
    
      + INIT() macros are used only in DEFINE() macros
    
      + init() functions are used close to the other kthread()
        functions. It looks much better if all the functions
        use the same scheme.
    
      + There will be also kthread_destroy_worker() that will
        be used close to kthread_cancel_work(). It is related
        to the init() function. Again it looks better if all
        functions use the same naming scheme.
    
      + there are several precedents for such init() function
        names, e.g. amd_iommu_init_device(), free_area_init_node(),
        jump_label_init_type(),  regmap_init_mmio_clk(),
    
      + It is not an argument but it was inconsistent even before.
    
    [arnd@arndb.de: fix linux-next merge conflict]
     Link: http://lkml.kernel.org/r/20160908135724.1311726-1-arnd@arndb.de
    Link: http://lkml.kernel.org/r/1470754545-17632-3-git-send-email-pmladek@suse.comSuggested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    3989144f
crypto_engine.c 12.2 KB