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

[Christoph Hellwig <hch@infradead.org>]

On Wed, Jun 28, 2017 at 04:01:34PM -0700, Kees Cook wrote:
> If there is time at the summit, I'd like to quickly discuss best
> practices for the mechanics of doing security defense development in
> the kernel. This has always been a bit tricky and I've done my best to
> navigate it, but it still feels like there are glitches that could be
> ironed out with a more clearly declared process (or ownership).

It's pretty hard as a general rule.  As someone who does a lot of
cross-subsystem work I usually try to find a "lead" subsystem to
funnel thing through, and if there isn't one yet I create it
(see the new uuid and dma-mappings ones for the next merge window).

> made in sources maintained outside the kernel itself (i.e. ACPICA)
> before they'd be accepted back into the kernel. Making tree-wide

And that's crap we just need to stop.  While I'm too some extent
ok with maintainers having their own little quirky requirements
on code style and organization that's simply a step too much.
Every subsystem in the kernel MUST accept suitable patches on the
proper, open mailing list.

And for ACPICA in general I think we'd reduce code size by 50%
and the bug amount by probably the same by stopping to treat it
special and apply the normal kernel rules to it.