Messages in this thread | | | Date | Wed, 1 Jun 2016 12:36:19 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v7 03/10] kthread: Add create_kthread_worker*() |
| |
On Mon, 30 May 2016 16:59:24 +0200 Petr Mladek <pmladek@suse.com> wrote:
> Kthread workers are currently created using the classic kthread API, > namely kthread_run(). kthread_worker_fn() is passed as the @threadfn > parameter. > > This patch defines create_kthread_worker() and > create_kthread_worker_on_cpu() functions that hide implementation details.
I hate to nick pits, but the naming isn't good.
A good, disciplined and pretty common naming scheme is to lead the overall identifier with the name of the relevant subsystem. kthread has done that *fairly* well:
Things we got right:
kthread_create_on_node kthread_create kthread_create_on_cpu kthread_run kthread_bind kthread_bind_mask kthread_stop kthread_should_stop kthread_should_park kthread_freezable_should_stop kthread_data kthread_park kthread_unpark kthread_parkme kthreadd kthread_work_func_t KTHREAD_WORKER_INIT KTHREAD_WORK_INIT KTHREAD_WORKER_INIT_ONSTACK kthread_worker_fn
Things we didn't:
probe_kthread_data DEFINE_KTHREAD_WORKER DEFINE_KTHREAD_WORK DEFINE_KTHREAD_WORKER_ONSTACK DEFINE_KTHREAD_WORKER_ONSTACK __init_kthread_worker init_kthread_worker init_kthread_work queue_kthread_work flush_kthread_work flush_kthread_worker
So I suggest kthread_create_worker() and kthread_create_worker_on_cpu(), please.
And this might be a suitable time to regularize some of the "things we didn't" identifiers, if you're feeling keen.
| |