From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleg Nesterov Subject: Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API Date: Sun, 7 Jun 2015 00:58:54 +0200 Message-ID: <20150606225854.GA20352@redhat.com> References: <1433516477-5153-1-git-send-email-pmladek@suse.cz> <1433516477-5153-12-git-send-email-pmladek@suse.cz> <20150606211648.GA15591@redhat.com> <20150606223001.GA18838@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jiri Kosina Cc: Petr Mladek , Andrew Morton , Tejun Heo , Ingo Molnar , Peter Zijlstra , Richard Weinberger , Steven Rostedt , David Woodhouse , linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Trond Myklebust , Anna Schumaker , linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chris Mason , "Paul E. McKenney" , Thomas Gleixner , Linus Torvalds , Borislav Petkov , Michal Hocko , live-patching-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-api@vger.kernel.org On 06/07, Jiri Kosina wrote: > > On Sun, 7 Jun 2015, Oleg Nesterov wrote: > > > > I personally don't see a huge principal difference between > > > "kthread_signal_dequeue() + kthread_do_signal_{stop,...}" vs. generic > > > "kthread_do_signal()" that's just basically completely general and > > > takes care of 'everything necessary'. > > > > Then why do we need the new API ? > > Well, in a nutshell, because of the "it's general and takes care of > everything" part. ... > Signal handling is just > one of the piggy-backers on top of this general cleanup. And to avoid the confusion: so far I only argued with the signal handling part of this API. Namely with kthread_do_signal(), especially with the SIG_DFL logic. If we want somthing like kthread_iterant agree it should probably help to handle the signals too. But afaics kthread_do_signal() doesn't really help and certainly it is not strictly necessary. Oleg. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z1N4Z-0004b6-7C for linux-mtd@lists.infradead.org; Sat, 06 Jun 2015 23:00:15 +0000 Date: Sun, 7 Jun 2015 00:58:54 +0200 From: Oleg Nesterov To: Jiri Kosina Subject: Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API Message-ID: <20150606225854.GA20352@redhat.com> References: <1433516477-5153-1-git-send-email-pmladek@suse.cz> <1433516477-5153-12-git-send-email-pmladek@suse.cz> <20150606211648.GA15591@redhat.com> <20150606223001.GA18838@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: linux-nfs@vger.kernel.org, Borislav Petkov , Thomas Gleixner , linux-api@vger.kernel.org, Peter Zijlstra , Richard Weinberger , Trond Myklebust , linux-kernel@vger.kernel.org, Petr Mladek , Michal Hocko , Chris Mason , Ingo Molnar , linux-mtd@lists.infradead.org, Steven Rostedt , Linus Torvalds , Tejun Heo , live-patching@vger.kernel.org, Andrew Morton , "Paul E. McKenney" , David Woodhouse , Anna Schumaker List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06/07, Jiri Kosina wrote: > > On Sun, 7 Jun 2015, Oleg Nesterov wrote: > > > > I personally don't see a huge principal difference between > > > "kthread_signal_dequeue() + kthread_do_signal_{stop,...}" vs. generic > > > "kthread_do_signal()" that's just basically completely general and > > > takes care of 'everything necessary'. > > > > Then why do we need the new API ? > > Well, in a nutshell, because of the "it's general and takes care of > everything" part. ... > Signal handling is just > one of the piggy-backers on top of this general cleanup. And to avoid the confusion: so far I only argued with the signal handling part of this API. Namely with kthread_do_signal(), especially with the SIG_DFL logic. If we want somthing like kthread_iterant agree it should probably help to handle the signals too. But afaics kthread_do_signal() doesn't really help and certainly it is not strictly necessary. Oleg. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:34661 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751986AbbFFW7y (ORCPT ); Sat, 6 Jun 2015 18:59:54 -0400 Date: Sun, 7 Jun 2015 00:58:54 +0200 From: Oleg Nesterov To: Jiri Kosina Cc: Petr Mladek , Andrew Morton , Tejun Heo , 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 , Borislav Petkov , Michal Hocko , live-patching@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API Message-ID: <20150606225854.GA20352@redhat.com> References: <1433516477-5153-1-git-send-email-pmladek@suse.cz> <1433516477-5153-12-git-send-email-pmladek@suse.cz> <20150606211648.GA15591@redhat.com> <20150606223001.GA18838@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: On 06/07, Jiri Kosina wrote: > > On Sun, 7 Jun 2015, Oleg Nesterov wrote: > > > > I personally don't see a huge principal difference between > > > "kthread_signal_dequeue() + kthread_do_signal_{stop,...}" vs. generic > > > "kthread_do_signal()" that's just basically completely general and > > > takes care of 'everything necessary'. > > > > Then why do we need the new API ? > > Well, in a nutshell, because of the "it's general and takes care of > everything" part. ... > Signal handling is just > one of the piggy-backers on top of this general cleanup. And to avoid the confusion: so far I only argued with the signal handling part of this API. Namely with kthread_do_signal(), especially with the SIG_DFL logic. If we want somthing like kthread_iterant agree it should probably help to handle the signals too. But afaics kthread_do_signal() doesn't really help and certainly it is not strictly necessary. Oleg.