Thread (62 messages) flat view 62 messages, 7 authors, 2015-06-17

Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API

From: Oleg Nesterov <hidden>
Date: 2015-06-06 23:00:04
Also in: linux-nfs, lkml

On 06/07, Jiri Kosina wrote:
On Sun, 7 Jun 2015, Oleg Nesterov wrote:
quoted
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help