From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Christoph Hellwig <hch@infradead.org>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Developing across multiple areas of the kernel
Date: Fri, 30 Jun 2017 15:02:13 +0200 [thread overview]
Message-ID: <CAKMK7uEXxc+dSvGk6XR1712h+VB3gDkOKbOmm7wnkvgN9HKdNg@mail.gmail.com> (raw)
In-Reply-To: <20170629133949.GA19691@infradead.org>
On Thu, Jun 29, 2017 at 3:39 PM, Christoph Hellwig <hch@infradead.org> wrote:
> 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).
I've only done cross-subsystem with 2-3 subsystems maybe for driver
work, and there the "topic branch in lead subsystem" plus maybe "send
pull requests to other subsystems when they insist they merge their
own patches through there tree" seems to work fairly well. Needs all
maintainers to understand the flow, but we've got that now scripted
entirely in drm so easy to do.
Large-scale cross-subsystem API stuff probably always needs multiple
releases, since you'll have some new usage grown no matter what. If
the current pace is too slow I guess we should think about shrinking
the release cycle maybe, to be able to sync up more often across
trees.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2017-06-30 13:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 23:01 Kees Cook
2017-06-29 13:39 ` Christoph Hellwig
2017-06-30 13:02 ` Daniel Vetter [this message]
2017-06-29 16:36 ` James Bottomley
2017-06-29 16:51 ` Kees Cook
2017-06-29 17:42 ` James Bottomley
2017-06-29 17:52 ` Kees Cook
2017-06-29 18:20 ` Luis R. Rodriguez
2017-06-29 19:07 ` Linus Torvalds
2017-06-29 20:16 ` Kees Cook
2017-06-29 20:27 ` Stephen Rothwell
2017-07-14 4:04 ` Leon Romanovsky
2017-07-14 9:54 ` Greg KH
2017-07-14 10:29 ` Leon Romanovsky
2017-07-14 14:10 ` Andrew Lunn
2017-07-14 15:05 ` Mark Brown
2017-07-14 15:51 ` Leon Romanovsky
2017-07-14 16:20 ` Mark Brown
2017-07-14 15:35 ` Leon Romanovsky
2017-07-14 15:43 ` James Bottomley
2017-07-14 16:08 ` Leon Romanovsky
2017-07-14 16:18 ` Andrew Lunn
2017-07-14 16:28 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKMK7uEXxc+dSvGk6XR1712h+VB3gDkOKbOmm7wnkvgN9HKdNg@mail.gmail.com \
--to=daniel.vetter@ffwll.ch \
--cc=hch@infradead.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox