Re: Towards __deprecated in cdefs.h

On Thu, Jul 25, 2024 at 3:12 PM Brooks Davis <brooks@freebsd.org> wrote:

> 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.
>

Yea. It also follows a few other things done as well...


> > 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.
>

 Yea...  The other way is to share better:
https://reviews.freebsd.org/D46144
and https://reviews.freebsd.org/D46145 so we share the fixes... I haven't
thought
about going the other direction...  I'll have to see what that looks like.

I had the same problems with the original OpenZFS boot loader integration:
It barely compiled, but was super fragile and tiny changes would break
it again and again while I was testing (eg rebase forward a few weeks
while testing). So I rewrote it to make it way simpler...

Warner