Re: Towards __deprecated in cdefs.h

On Thu, Jul 25, 2024 at 5:57 PM Warner Losh <[email protected]> wrote:

>
>
> On Thu, Jul 25, 2024 at 3:12 PM Brooks Davis <[email protected]> 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...
>

vs https://reviews.freebsd.org/D46146 which just starts to scratch the
surface.

There's a lot of other stuff that can likely be trimmed.

Warner