Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] API replacement/deprecation

[Maxime Ripard <maxime.ripard@bootlin.com>]

[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]

Hi Kees,

On Thu, Sep 06, 2018 at 11:24:11AM -0700, Kees Cook wrote:
> On Wed, Sep 5, 2018 at 7:24 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Thu, 6 Sep 2018 09:41:58 +1000
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> On Wed, 5 Sep 2018 15:57:02 -0700 Kees Cook <keescook@chromium.org> wrote:
> >> >
> >> > I'd like to discuss ways that we could deprecate APIs more sanely. At
> >> > present I've seen (and used) two approaches, fast and slow:
> >>
> >> As the one who often has the "fun" of coping with API changes, I would
> >> like to be involved in this discussion.
> >>
> >> My first point would be that (almost) every time someone has tried the
> >> "ultra fast" method (i.e. add new interface, convert everyone in the
> >> current kernel, remove the old interface all in one go) we have had new
> >> users of the old interface introduced at the same time.  (pain for the
> >> linux-next bunny :-()
> >
> > Can this be solved with a script on kernel.org? Or a zero-day bot that
> > checks new commits (and perhaps patches to LKML) that checks for
> > deprecated functions being added by new code (like strcpy) and the
> > author would then get a nasty email about adding deprecated interfaces.
> >
> > This would solve the issue of not everyone using the latest checkpatch,
> > as this wouldn't be a voluntary self-check. It would also quickly
> > educate developers on what code is not acceptable to be added.
> 
> I think this boils down to how our development ecosystem works. Things
> are pretty "voluntary" right now: one could easily ignore zero-day or
> checkpatch all the time, and if a maintainer isn't checking these
> things, a patch will go in.

I have the feeling that the problem is a bit different than what
you're actually describing. It's not so much that we ignore (as in
voluntarily ignore) these new deprecated functions, but more that it's
quite easy to overlook them if you're not following closely the
current effort being done, especially when you don't really have a
security culture.

And then, there's some changes where the benefit is really not obvious
(kmalloc_array comes to my mind).

Polling actively some file isn't going to work, since well, we're all
too busy and lazy to actually do that, but maybe adding
warnings/errors to checkpatch would help, in a similar way than what's
being done for the msleep vs mdelay warning, with a link to the
documentation to explain why that is needed in the first place.

I think that this would help to address the discoverability of those
API changes.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]