Re: Towards __deprecated in cdefs.h

On Thu, Jul 25, 2024 at 01:41:06PM -0600, Warner Losh wrote:
> There's often times we want to mark interfaces as allowed, but please stop
> using it.
> 
> C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]] forms. It
> would be nice to start using it.
> 
> The question is how.
> 
> Linux adopted, then effectively abandoned, __deprecated as a decorator. At
> first, it would produce warnings, but water was changed to be just
> ornamental because too many warnings were thrown during a kernel build.
> 
> So position [1] is to do what Linux did. Make iit a #define that does
> nothing.
> 
> Position [2] is do what Linux did originally: make it a warning to use
> deprecated interfaces (but likely a -Wno-error warning).
> 
> However, it would be nice sometimes to have a message that goes along with
> the use. Sadly, there's no way to have a macro in C or C++ that either
> takes an argument or doesn't. You either get pure replacement, or you get
> parameterized replacement, but never both. So, we'd need
> __deprecated_str or __deprecated_msg that took an optional message to give.
> This form would always warn, but could be paired with either [1] or [2] as
> [3] and [4].
> 
> Since we're talking about a macro that's slightly different than Linux,
> should it have a different name, in which case we'd have __dep and
> __dep_msg(x) as [5] and [6].
> 
> There's likely more crazy, but that's likely too crazy to contemplate.
> 
> Personally, I think that option [4] is best: have __deprecated and
> __deprecated_msg(x), both of which always warn.
> 
> We don't need a __deprecated_error, I don't think. We get the same effect
> by removing it entirely, or removing its declaration from the .h file while
> keeping ot global.
> 
> So before I spend a ton of time on implementing the various options, I
> thought I'd poll on arch@ to see if there's agreement that [4] is likely
> best, and if not, which other option I should put my weight behind. I
> realized I needed a wider discussion when I did [2] in
> https://reviews.freebsd.org/D46137 and the ensuing conversation in IRC
> didn't have 'no-brainer yes' written all over it.

[4] with a message variant works for me.  It's close to the standard thing
and makes it easy to see what you should be doing.

> The down side of doing [4] is we'll have to also change OpenZFS... but we
> likely should do that anyway since OpenZFS opted to use a copy of the
> linuxkpi compiler.h file rather than #include it and make minor mods :(.
> Maybe I'll make a patch for that too, or maybe I'll fix up
> https://github.com/openzfs/zfs/pull/16388

IMO this file should be pared down to only things OpenZFS uses in
shared code (__deprecated is not).  It looks typical of the ZoL ->
FreeBSD port in that overly broad shims where copied and hacked until
the thing compiled, but then no effort was made to slim them down.  See
ecbf02791f9 in OpenZFS for another example.

-- Brooks