Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Developing across multiple areas of the kernel

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2017-06-28 at 16:01 -0700, Kees Cook wrote:
> For refcount_t, the conversions have been going per-maintainer, and
> while this is likely the right way to do things, there are
> dependencies that are crossing releases, which seems inefficient. For
> example, obviously doing a refcount_t conversion requires the
> refcount_t implementation first (which landed in v4.11), but then
> later conversions wanted an option for a light implementation
> (expected for v4.13), but in both cases most maintainers wanted the
> implementations entirely landed, not just in -next (vast majority of
> refcount_t conversions currently in the kernel landed in v4.12, so
> the next wave will have to wait until v4.14 it seems). This appears
> mostly to be about avoiding tree dependencies, IIUC, but is an
> awfully slow way to do things.

Given the performance concerns of the first implementation, this
timetable and the interactions that went with it seem to be pretty much
textbook correct, especially as none of the hot paths seemed
susceptible to overflow attacks.

Any other way would have produced a lot more friction: imagine if it
had been done tree at once for 4.12 and then performance had tanked and
we'd got reversions all over the place ... you'd be spending a lot more
than a couple of kernel releases trying to persuade maintainers to take
the new improved stuff.

James