From: Julia Lawall <julia.lawall@lip6.fr>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] API replacement/deprecation
Date: Thu, 6 Sep 2018 08:12:21 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1809060806110.3065@hadrien> (raw)
In-Reply-To: <20180905222437.5d2a1730@vmware.local.home>
On Wed, 5 Sep 2018, Steven Rostedt wrote:
> On Thu, 6 Sep 2018 09:41:58 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > 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.
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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
next prev parent reply other threads:[~2018-09-06 6:12 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 22:57 Kees Cook
2018-09-05 23:41 ` Stephen Rothwell
2018-09-06 2:24 ` Steven Rostedt
2018-09-06 6:12 ` Julia Lawall [this message]
2018-09-06 18:24 ` Kees Cook
2018-09-06 23:18 ` Stephen Rothwell
2018-09-06 23:24 ` Kees Cook
2018-09-07 7:03 ` Takashi Iwai
2018-09-07 7:20 ` Johannes Berg
2018-09-07 7:31 ` Takashi Iwai
2018-09-07 9:42 ` Julia Lawall
2018-09-07 8:04 ` Jani Nikula
2018-09-07 9:38 ` Julia Lawall
2018-09-07 9:54 ` Jani Nikula
2018-09-07 10:05 ` Julia Lawall
2018-09-07 10:43 ` Jani Nikula
2018-09-07 10:25 ` Alexandre Belloni
2018-09-07 11:44 ` Mark Brown
2018-09-10 12:51 ` Mauro Carvalho Chehab
2018-09-11 8:10 ` Jani Nikula
2018-09-11 9:34 ` Mauro Carvalho Chehab
2018-09-11 11:08 ` Arnd Bergmann
2018-09-07 8:19 ` Jan Kara
2018-09-07 14:33 ` Theodore Y. Ts'o
2018-09-07 16:10 ` Kees Cook
2018-09-07 20:30 ` Arnd Bergmann
2018-09-07 20:56 ` Theodore Y. Ts'o
2018-09-08 8:15 ` Geert Uytterhoeven
2018-09-08 15:19 ` Theodore Y. Ts'o
2018-09-10 12:28 ` Mauro Carvalho Chehab
2018-09-10 16:09 ` Kees Cook
2018-09-07 10:14 ` Dan Carpenter
2018-09-07 10:40 ` Geert Uytterhoeven
2018-09-07 8:40 ` Maxime Ripard
2018-09-06 4:44 ` Julia Lawall
2018-09-06 10:04 ` Linus Walleij
2018-09-06 10:11 ` Geert Uytterhoeven
2018-09-06 14:59 ` Kees Cook
2018-09-06 15:06 ` Geert Uytterhoeven
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=alpine.DEB.2.20.1809060806110.3065@hadrien \
--to=julia.lawall@lip6.fr \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=rostedt@goodmis.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