From nobody Thu Jul 25 23:57:12 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WVSVY5hS8z5Rb26 for ; Thu, 25 Jul 2024 23:57:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVSVY1vZpz4d4K for ; Thu, 25 Jul 2024 23:57:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-7a0c6ab3354so359226a12.0 for ; Thu, 25 Jul 2024 16:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721951844; x=1722556644; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tsP6XiipwBOIHo38kUPLlkjSb7jS47Q3UJ27zNv2vEg=; b=hftlfh3wpHiDcsD9AzrEf7MNnV1/TqVhlUiR9Uu5VwaJpffk95eLJ0zM83D1zywV6N VZDZMT4MDk4WYBs3pmo2KyPxxMp7lSY+UXTYCsdgeJvPaDgwpWLrPQ4XVUGnduH8BdGA i4lf21N8ChpWVs88/vS8o0Qt0fQcqYN1fYG416oLRAwsk2jiSEdBT9K3bxKRiWfEyL3x jlKVb7R4p/FNTrjTorYGpxxRdSiK0+rpJacDL9oQPjr79zkb+Nm/lgb/7QVhjkAdIkVb tJ0E/vmdGsZKPlpBAhRmNp/N0YQniRWfmUPBvvFjpqlY+9LFM5mihSDz8FwhjRwWycbA 26Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721951844; x=1722556644; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tsP6XiipwBOIHo38kUPLlkjSb7jS47Q3UJ27zNv2vEg=; b=TRa21ass+a2Ozsz8W1I9PprWO92S+qoEtmxN7DKtaOQYZgnnD5ggJT3Gz/LHLGy4UZ QKj+qhbLqSJ+Qs2kACM4GD66t9Xpac9nLPUiiPiyDyWn3dvmIgqCrr+DF7Q+qBZYZc1y rqoWip+LxEEzNxvnGL4OnH57VTV3rS2fXjZMnqGdtM4SpbS3Qt0TzeSW+ZVB/PBJ0CIl tc479h61qOhEOzMzAyhn96YeU07TeoPSCwOZiv1lotrkhpCcBxf2S3e1rYOqGWfpJxaJ sv+73iFC/dBoZ0mY3JxtXXQluG566+FwZY7Zly4iRuMDKzS+1bpmt47OXU0jgCRAa4Yy /4/w== X-Gm-Message-State: AOJu0Yw6vcKxu15yC/hX8RGHLO4+PlICC1KO5NSsYwqGq0P44/wT9Wkb v3P6lSttOHNkay2Msq9ocEXhYiyKdQ1jOWDNbDcs5hznJREE9F8II8TXlhv9R6HjDhPjLFaEokh FckaSoo80mkJZ/MZhQDwyriLiqStMgznsBOI8zvEWgBRM7xWV6yJEXg== X-Google-Smtp-Source: AGHT+IE0PMgHIX2cjj1z5zOGLxvUqeOOgIL5lEEyWVJpE18dNN235pEQkNna6zUS2B8qLHAYOJkJiGgbgBkI5XcrZm0= X-Received: by 2002:a17:90a:f48f:b0:2cd:b938:770b with SMTP id 98e67ed59e1d1-2cf2e9b30a2mr3877026a91.5.1721951843713; Thu, 25 Jul 2024 16:57:23 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 25 Jul 2024 17:57:12 -0600 Message-ID: Subject: Re: Towards __deprecated in cdefs.h To: Brooks Davis Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000f72425061e1b27f6" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WVSVY1vZpz4d4K --000000000000f72425061e1b27f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2024 at 3:12=E2=80=AFPM Brooks Davis w= rote: > 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 g= et > > 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 effe= ct > > 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 likel= y > > 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 thin= g > 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 --000000000000f72425061e1b27f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 25, 2024 at 3:12=E2=80=AF= PM Brooks Davis <brooks@freebsd.or= g> 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 ple= ase 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<= br> > 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 ei= ther
> 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 th= an 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 cont= emplate.
>
> 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<= br> > realized I needed a wider discussion when I did [2] in
> https://reviews.freebsd.org/D46137 and the ensuing conver= sation in IRC
> didn't have 'no-brainer yes' written all over it.

[4] with a message variant works for me.=C2=A0 It's close to the standa= rd thing
and makes it easy to see what you should be doing.
Yea. It also follows a few other things done as well...
=C2=A0
> 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<= br> > 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).=C2=A0 It looks typical of the ZoL -><= br> 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.=C2=A0 Se= e
ecbf02791f9 in OpenZFS for another example.

=
=C2=A0Yea...=C2=A0 The other way is to share better:=C2=A0https://reviews.freebsd.org/D46144
and=C2=A0https://re= views.freebsd.org/D46145 so we share the fixes... I haven't thought=
about going the other direction...=C2=A0 I'll have to see wh= at that looks like.

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

W= arner
--000000000000f72425061e1b27f6--