From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 685F1E6B for ; Fri, 7 Sep 2018 08:04:53 +0000 (UTC) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D92148B for ; Fri, 7 Sep 2018 08:04:52 +0000 (UTC) From: Jani Nikula To: Takashi Iwai , Kees Cook In-Reply-To: References: <20180906094158.1eba4f50@canb.auug.org.au> <20180905222437.5d2a1730@vmware.local.home> <20180907091842.6c55bd9a@canb.auug.org.au> Date: Fri, 07 Sep 2018 11:04:16 +0300 Message-ID: <87zhwtybr3.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] API replacement/deprecation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 07 Sep 2018, Takashi Iwai wrote: > On Fri, 07 Sep 2018 01:24:03 +0200, > Kees Cook wrote: >> >> On Thu, Sep 6, 2018 at 4:18 PM, Stephen Rothwell wrote: >> > Hi Kees, >> > >> > On Thu, 6 Sep 2018 11:24:11 -0700 Kees Cook wrote: >> >> >> >> If there was an agreement by all maintainers that deprecated >> >> functions/patterns should not be added, and we documented the >> >> deprecation somewhere like Documentation/process/deprecated.rst, then >> >> we could make the declaration that if such functions got added (it's >> >> easy to mechanically check for them), it would be the responsibility >> >> of the author and maintainer chain to see that it got fixed before the >> >> release is cut. We already have this for things like "breaks the x86 >> >> allmodconfig build" or similar. The checking would be manual, and the >> >> enforcement would be by agreement, but it'd be better than the kind of >> >> "please don't do this" hand-waving we've had in the past. >> > >> > I could do this in linux-next, of course, the same way I check for >> > missing signed-off-bys. All I would need is the list of deprecated >> > things. >> >> Hopefully we can all agree on deprecating strcpy() and strncpy() in >> favor of strscpy()? > > How about providing some lightweight check script for git commit hook, > and let each maintainer install it? I looked up 771c035372a0 ("deprecate the '__deprecated' attribute warnings entirely and for good"). It's easy to agree that's the right thing to do for the regular build. However, I think there's value in having __deprecated tagged to functions. (Note, just that, without defining it as __attribute__((deprecated)).) People looking the functions up can see they should find alternatives, and people looking for things to do could take on the conversion. I don't think a separate deprecated file will work. It's all too detached. Then you can just use -D__deprecated=__attribute__((deprecated)) to get the warnings when you like, even on a per module/file basis, or add that to W=, or add that to 0-day or whatever CI, ensuring patches aren't adding new warnings. No need to invent wheels for things where the compiler can help. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center