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

Julia Lawall julia.lawall at lip6.fr
Thu Sep 6 06:12:21 UTC 2018



On Wed, 5 Sep 2018, Steven Rostedt wrote:

> On Thu, 6 Sep 2018 09:41:58 +1000
> Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > On Wed, 5 Sep 2018 15:57:02 -0700 Kees Cook <keescook at 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.

There are some Coccinelle scripts already for functions the DRM people
want to get rid of.  They regularly trigger reports.  The advantage is to
show people what they should do, and not just tell people what they should
not do.  There could be a generic script that would just complain, for
cases where the relation between the undesired code and the desired code
is not easy to express.  Updating such a script would involve just adding
the name of the function to a list.

julia

>
> 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.
>
> -- Steve
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>


More information about the Ksummit-discuss mailing list