linux-kernel - Re: [PATCH v8 02/12] kthread: Kthread worker API cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160613120333.47141cd9@gandalf.local.home>
Date:	Mon, 13 Jun 2016 12:03:33 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Petr Mladek <pmladek@...e.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Josh Triplett <josh@...htriplett.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>, Borislav Petkov <bp@...e.de>,
	Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
	Vlastimil Babka <vbabka@...e.cz>, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 02/12] kthread: Kthread worker API cleanup

On Mon, 13 Jun 2016 17:13:53 +0200
Petr Mladek <pmladek@...e.com> wrote:

> OK, all wants to keep DEFINE stuff as is:
> 
>   DEFINE_KTHREAD_WORKER()		stay
>   DEFINE_KTHREAD_WORK()			stay
>   DEFINE_KTHREAD_WORKER_ONSTACK()	stay
>   DEFINE_KTHREAD_WORKER_ONSTACK()	stay
> 
> 
> Nobody was against renaming the non-init functions:
> 
>   insert_kthread_work()		-> kthread_insert_work()
>   queue_kthread_work()		-> kthread_queue_work()
>   flush_kthread_work()		-> kthread_flush_work()
>   flush_kthread_worker()	-> kthread_flush_worker()

Yep.

> 
> 
> 
> Now, the question seem to be the init() functions.
> Andrew would prefer:
> 
>   __init_kthread_worker()	-> __kthread_worker_init()
>   init_kthread_worker()		-> kthread_worker_init()
>   init_kthread_work()		-> kthread_work_init()
> 
> AFAIK, Steven would prefer to keep it
> 
>   __init_kthread_worker()	stay as is
>   init_kthread_worker()		stay as is
>   init_kthread_work()		stay as is
> 
> I would personally prefer the way from this patch:
> 
>   __init_kthread_worker()	-> __kthread_init_worker()
>   init_kthread_worker()		-> kthread_init_worker()
>   init_kthread_work()		-> kthread_init_work()
> 
> 
> I have several reasons:
> 
> 1. The init functions will be used close to the other functions in
>    the code. It will be easier if all functions use the same
>    naming scheme. Here are some snippets:
> 
> 	kthread_init_work(&w_data->balancing_work, clamp_balancing_func);
> 	kthread_init_delayed_work(&w_data->idle_injection_work,
> 				  clamp_idle_injection_func);
> 	kthread_queue_work(w_data->worker, &w_data->balancing_work);
> 
>    or
> 
> 	kthread_init_delayed_work(&kmemleak_scan_work, kmemleak_scan_func);
> 	kmemleak_scan_worker = kthread_create_worker(0, "kmemleak");
> 
> 
> 2. We are going to add kthread_destroy_worker() which would need
>    to be another exception. Also this function will be used together
>    with the others, for example:
> 
> 	kthread_cancel_delayed_work_sync(&rb_producer_hammer_work);
> 	kthread_destroy_worker(rb_producer_worker);
> 
>    Also here the same naming scheme will help.
> 
> 
> 3. It is closer to the workqueues API, so it reduces confusion.

Using workqueues as an example of "reduces confusion" is not the most
convincing argument ;-)

> 
> 4. Note that there are already several precedents, for example:
> 
> 	amd_iommu_init_device()
> 	free_area_init_node()
> 	jump_label_init_type()
> 	regmap_init_mmio_clk()
> 
> 
> Andrew, Steven, are you really so strongly against my version
> of the init functions, please?
> 
> 

I don't really have that strong opinion on the "init" part. I was much
more concerned about the DEFINE/DECLARE macros.

-- Steve