Return-Path: Received: from mail-pa0-f52.google.com ([209.85.220.52]:34373 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752240AbbFIH6W (ORCPT ); Tue, 9 Jun 2015 03:58:22 -0400 Date: Tue, 9 Jun 2015 16:58:08 +0900 From: Tejun Heo To: Petr Mladek Cc: Andrew Morton , Oleg Nesterov , Ingo Molnar , Peter Zijlstra , Richard Weinberger , Steven Rostedt , David Woodhouse , linux-mtd@lists.infradead.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Chris Mason , "Paul E. McKenney" , Thomas Gleixner , Linus Torvalds , Jiri Kosina , Borislav Petkov , Michal Hocko , live-patching@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 00/18] kthreads/signal: Safer kthread API and signal handling Message-ID: <20150609075808.GA11955@mtj.duckdns.org> References: <1433516477-5153-1-git-send-email-pmladek@suse.cz> <20150609061025.GU21465@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20150609061025.GU21465@mtj.duckdns.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: Hello, Petr. I've skimmed through the patchset and I'm not quite sure. kthread_iterant seems to map almost one to one to kthread_worker interface. One calls a predefined callback repeatedly while the other queues work items which contain callback. One does nasty plumbing tasks inbetween interations, the other does inbetween work items. One has sleep helper to sleep "safely", the other can use delayed work items and flushing cancel. In fact, I'm pretty sure it'd be trivial to convert between the two sets of API. If so, is it really worthwhile to introduce the new API? kthread_iterant is closer to raw kthread but not quite. It shouldn't be difficult to apply the bulk of kthread_iterant's features to kthread_worker. Wouldn't it be more beneficial to have async execution mechanisms more closely aligned? Thanks a lot. -- tejun