All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Kent Overstreet <kent.overstreet@linux.dev>,
	linux-bcachefs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [GIT PULL] bcachefs updates for 6.8
Date: Thu, 11 Jan 2024 15:42:19 -0800	[thread overview]
Message-ID: <202401111534.859084884C@keescook> (raw)
In-Reply-To: <ZaByTq3uy0NfYuQs@casper.infradead.org>

On Thu, Jan 11, 2024 at 10:57:18PM +0000, Matthew Wilcox wrote:
> On Wed, Jan 10, 2024 at 05:47:20PM -0800, Linus Torvalds wrote:
> > No, because the whole idea of "let me mark something deprecated and
> > then not just remove it" is GARBAGE.
> > 
> > If somebody wants to deprecate something, it is up to *them* to finish
> > the job. Not annoy thousands of other developers with idiotic
> > warnings.
> 
> What would be nice is something that warned about _new_ uses being
> added.  ie checkpatch.  Let's at least not make the problem worse.

For now, we've just kind of "dealt with it". For things that show up
with new -W options we've enlisted sfr to do the -next builds with it
explicitly added (but not to the tree) so he could generate nag emails
when new warnings appeared. That could happen if we added it to W=1
builds, or some other flag like REPORT_DEPRECATED=1.

Another ugly idea would be to do a treewide replacement of "func" to
"func_deprecated", and make "func" just a wrapper for it that is marked
with __deprecated. Then only new instances would show up (assuming people
weren't trying to actively bypass the deprecation work by adding calls to
"func_deprecated"). :P Then the refactoring to replace "func_deprecated"
could happen a bit more easily.

Most past deprecations have pretty narrow usage. This is not true with
the string functions, which is why it's more noticeable here. :P

-Kees

-- 
Kees Cook

  reply	other threads:[~2024-01-11 23:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-10 19:36 [GIT PULL] bcachefs updates for 6.8 Kent Overstreet
2024-01-10 23:48 ` Kees Cook
2024-01-11  0:04   ` Kent Overstreet
2024-01-11  0:39     ` Kees Cook
2024-01-11  0:58       ` Kent Overstreet
2024-01-11  1:47         ` Linus Torvalds
2024-01-11 22:57           ` Matthew Wilcox
2024-01-11 23:42             ` Kees Cook [this message]
2024-01-11 23:58               ` Linus Torvalds
2024-01-12  0:05               ` Kent Overstreet
2024-01-12  0:18                 ` Kees Cook
2024-01-11 15:35         ` Mark Brown
2024-01-11 17:38           ` Kent Overstreet
2024-01-11 21:47             ` Mark Brown
2024-01-12  1:10               ` Kent Overstreet
2024-01-12 11:11                 ` Neal Gompa
2024-01-12 18:22                   ` Mark Brown
2024-01-15 18:42                     ` Kent Overstreet
2024-01-15 20:13                       ` Greg KH
2024-01-17  4:41                         ` Kent Overstreet
2024-01-17  5:31                           ` Greg KH
2024-01-17  5:54                           ` Theodore Ts'o
2024-01-17 13:03                             ` James Bottomley
2024-01-17 18:19                               ` Mark Brown
2024-01-21  3:24                                 ` Kent Overstreet
2024-01-25 21:46                                   ` Mark Brown
2024-01-18  2:49                               ` Theodore Ts'o
2024-01-21 12:20                                 ` Kent Overstreet
2024-01-24  5:52                                   ` Theodore Ts'o
2024-01-18  5:35                               ` Randy Dunlap
2024-01-21  2:49                               ` Kent Overstreet
2024-01-17 17:33                       ` Mark Brown
2024-01-11  2:23 ` pr-tracker-bot

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=202401111534.859084884C@keescook \
    --to=keescook@chromium.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.