Re: [PATCH 1/1] kthreads: allow_signal: don't play with ->blocked

Matt Fleming
2011-08-17T09:57:05Z

On Wed, 2011-08-17 at 09:27 +0200, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 16, 2011 at 10:50:22PM +0100, Matt Fleming wrote:
> >
> > But because daemonize() is exported by the kernel should it go through
> > the Documentation/feature-removal-schedule.txt procedure? And if so, can
> > the allow_signal() patch still go in before daemonize() is removed?
>
> IMHO, not really. APIs get modified and dropped all the time and only
> small fraction goes through feature-removal-schedule. For APIs which
> are widely used and/or difficult to migrate from, it sure makes sense
> to do the staged removal but in this case it's an interface which is
> quite unpopular and with relatively easy workaround (just use
> kthread).
>
> The worst thing we can do regarding API change is silently changing
> semantics while not changing the interface. For this patchset I don't
> think it would matter all that much but is going that route.
> ie. allow_signal() behavior is proposed to be changed because
> in-kernel daemonize() users don't depend on it while leaving
> daemonize() alone. This is much worse than simply removing
> daemonize() with sufficient explanation in the commit message.
> Out-of-kernel user which depended on the combination working would now
> be left with code which compiles fine but behaves differently, which
> sucks big time.
>
> These changes _are_ related and interdependent, and routing these
> small changes through different trees often end up delaying things
> unnecessarily. One subsystem maintainer forgets to apply a patch or
> send pull request and it can get easily drawn out half a year and
> people forget what the original change was about after a while often
> leading to half done conversions. So, let's please collect all the
> related patches into one series, drop all in-kernel daemonize() users,
> kill daemonize() and then change allow_signal() behavior.

OK, that makes a lot of sense to me. Thanks for the rationale.

Oleg, feel to carry over my Acked-by's for the patches you've already
posted if you decide to go ahead with Tejun's plan.

--
Matt Fleming, Intel Open Source Technology Center