Date: Thu, 25 Jul 2024 13:41:06 -0600 From: Warner Losh <imp@bsdimp.com> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Towards __deprecated in cdefs.h Message-ID: <CANCZdfpBqNdAUK4R5YvQng3TpAPCUE%2B0ft5Q_xfRc6VuZoQWMw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--000000000000160092061e17946f
Content-Type: text/plain; charset="UTF-8"
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.
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
Warner
--000000000000160092061e17946f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There's often times we want to mark interfaces=C2=A0as=
allowed, but please stop using it.<div><br></div><div>C23 has a new, fancy=
[[deprecated]] and [[deprecated("msg")]] forms. It would be nice=
to start using it.</div><div><br></div><div>The question is how.</div><div=
><br></div><div>Linux adopted, then effectively abandoned, __deprecated as =
a decorator. At first, it would produce warnings, but water was changed to =
be just ornamental=C2=A0because too many warnings were thrown during a kern=
el build.</div><div><br></div><div>So position [1] is to do what Linux did.=
Make iit a #define that does nothing.</div><div><br></div><div>Position [2=
] is do what Linux did originally: make it a warning to use deprecated inte=
rfaces (but likely a -Wno-error warning).</div><div><br></div><div>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 param=
eterized replacement, but never both. So, we'd need</div><div>__depreca=
ted_str or __deprecated_msg that took an optional message to give. This for=
m would always warn, but could be paired with either [1] or [2] as [3] and =
[4].</div><div><br></div><div>Since we're talking about a macro that=
9;s slightly different than Linux, should it have a different name, in whic=
h case we'd have __dep and __dep_msg(x) as [5] and [6].</div><div><br><=
/div><div>There's likely more crazy, but that's likely too crazy to=
contemplate.</div><div><br></div><div>Personally, I think that option [4] =
is best: have __deprecated and __deprecated_msg(x), both of which always wa=
rn.</div><div><br></div><div>We don't need a __deprecated_error, I don&=
#39;t think. We get the same effect by removing it entirely, or removing it=
s declaration from the .h file while keeping ot global.</div><div><br></div=
><div>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=C2=A0<a href=3D"h=
ttps://reviews.freebsd.org/D46137">https://reviews.freebsd.org/D46137</a>; a=
nd the ensuing conversation in IRC didn't have 'no-brainer yes'=
written all over it.</div><div><br></div><div>The down side of doing [4] i=
s we'll have to also change OpenZFS... but we likely should do that any=
way since OpenZFS opted to use a copy of the linuxkpi=C2=A0compiler.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=C2=A0<a href=3D"https://github.com/=
openzfs/zfs/pull/16388">https://github.com/openzfs/zfs/pull/16388</a></div>=
<div><br></div><div>Warner</div></div>
--000000000000160092061e17946f--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpBqNdAUK4R5YvQng3TpAPCUE%2B0ft5Q_xfRc6VuZoQWMw>