[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 7 Jun 2015 00:30:01 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Jiri Kosina <jkosina@...e.cz>
Cc: Petr Mladek <pmladek@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Richard Weinberger <richard@....at>,
Steven Rostedt <rostedt@...dmis.org>,
David Woodhouse <dwmw2@...radead.org>,
linux-mtd@...ts.infradead.org,
Trond Myklebust <trond.myklebust@...marydata.com>,
Anna Schumaker <anna.schumaker@...app.com>,
linux-nfs@...r.kernel.org, Chris Mason <clm@...com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Borislav Petkov <bp@...e.de>, Michal Hocko <mhocko@...e.cz>,
live-patching@...r.kernel.org, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into
the iterant API
On 06/06, Jiri Kosina wrote:
>
> On Sat, 6 Jun 2015, Oleg Nesterov wrote:
>
> > Still I personally dislike the new kthread_sigaction() API. I agree,
> > a couple if signal helpers for kthreads make sense. Say,
> >
> > void kthread_do_signal_stop(void)
> > {
> > spin_lock_irq(&curtent->sighand->siglock);
> > if (current->jobctl & JOBCTL_STOP_DEQUEUED)
> > __set_current_state(TASK_STOPPED);
> > spin_unlock_irq(¤t->sighand->siglock);
> >
> > schedule();
> > }
>
> ... not to mention the fact that 'STOP' keyword in relation to kthreads
> has completely different meaning today, which just contributes to overall
> confusion; but that's an independent story.
Yes, agreed.
> > But personally I do not think kthread_do_signal() makes a lot of sense...
>
> Would it be possible for you to elaborate a little bit more why you think
> so ... ?
Please see another email I sent in reply to 06/18.
> 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 ?
And I do see the difference. Rightly or not I belive that this API buys
nothing but makes the kthread && signal interaction more complex and
confusing. For no reason.
But!
> That being said, my relationship to signal
> handling code is of course much less intimate compared to yours,
No, no, no, this doesn't matter at all ;)
Yes I do dislike this API. So what? I can be wrong. So if other reviewers
like it I will hate them all ^W^W^W not argure. So please comment. I never
trust myself unless I can technically (try to) prove I am right. In this
case I can't, this is only my feeling.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists