On Thu, Jan 11, 2024 at 07:05:06PM -0500, Kent Overstreet wrote: > On Thu, Jan 11, 2024 at 03:42:19PM -0800, Kees Cook wrote: > > 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 > > Before doing the renaming - why not just leave a kdoc comment that marks > it as deprecated? Seems odd that checkpatch was patched, but I can't > find anything marking it as deprecated when I cscope to it. It doesn't explicitly say "deprecated", but this language has been in the kdoc for a while now (not that people go read this often): * Do not use this function. While FORTIFY_SOURCE tries to avoid * over-reads when calculating strlen(@q), it is still possible. * Prefer strscpy(), though note its different return values for * detecting truncation. But it's all fine -- we're about to wipe out strlcpy for v6.8. Once the drivers-core and drm-misc-next trees land, (and the bcachefs patch[1]) we'll be at 0 users. :) -Kees [1] https://lore.kernel.org/lkml/20240110235438.work.385-kees@xxxxxxxxxx/ -- Kees Cook
