From nobody Fri Jul 26 00:18:43 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 4WVSzQ2W3Mz5RcVv for ; Fri, 26 Jul 2024 00:18:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 4WVSzP0d9zz4fb9 for ; Fri, 26 Jul 2024 00:18:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=peliWtGD; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::1032) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2cb57e25387so322817a91.3 for ; Thu, 25 Jul 2024 17:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721953135; x=1722557935; 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=oE99sWS8vvNXHPXiTsy/TQ3gMk6mMeLzwtCj89inl7M=; b=peliWtGDXploa4+JcvggMfAM1ZghcXAPPJaQRiMrSc6dGwzUYL2lelem1Z5VoYZhJ0 3nAt5hW9ZxUsJvS0CMoc7b8ItbU+1HnOTSYMkb9mBaY1cKdNjjso4jlAQSAS/tWF51A0 5WJJrqu6JmnK/3xwESWFU3DyGndWcOa/SVKHVdQRmkRGd4ilmTqYoLPc5PRT4s5N6tsg QB8VyihkZDsyVpPK4nYDW3h//dJ1CQoIADqCHIoQi3ZrhEP2FR4BtcRuU/gK5vVqKAEt 5FMwZw4ep+zEqf0Mhu6ALJTJB9o5Unjd/dw/FZvhkR1oE63ucDbn0oE+6STVbJ5Q5YqI oiBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721953135; x=1722557935; 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=oE99sWS8vvNXHPXiTsy/TQ3gMk6mMeLzwtCj89inl7M=; b=aDTzP94CONhhkn7/hl6Zkrk7TAnGLdv/iNbsHb9jveWHNmyrbgsGqB03MaFgnHTv9P QzA0nhFyMJujhgk8h2pUjaY1uDRETrSvKnWwZm2fa1iBBzSmgsReuw6Chmd6F3ykEtXA AVxJd9uIe7dXk6rtzqdZ71PKwLGwAsz+6IXnVkqgalCKFACdZWFlnL7FUvpZYqXHgLJw FaVGbQs/enl4jEkWYAK+Pl/FI7qETx7/ydzqzkRD5wuCimAICuxWDMmSC/vILx4Q3rFX cL1cjnpmUkkDr1wZY+NjwdrJWAXySNCzA1V5vm96wHGuoBUKIt81C72vlmZKnq19uCaN oE0A== X-Gm-Message-State: AOJu0YyoDGh5vlR370m5joATxjT2tI7QK9vGP6XbeGV2/SVMTub+sDmu Y3EX621L4k76SGaUQNsdHYVCBYMFYmf8YyiSNVYW3ZHaalwEXXkL52EwSZ7MmoeYmxS8G1vAO1Y bpZnMfXcfb5gO17db2a5UaTQym7o9R96haxAcyVH3D02UbEYF3e1Kng== X-Google-Smtp-Source: AGHT+IEis/kDmFXtvtWeiv7FfUcHUCz/ZPHoykVKyNH9dMHeWGrYHRdLnxg/addsv5pnJl1A4lN0OznhZQetzADDCOw= X-Received: by 2002:a17:90b:274c:b0:2ca:7636:2214 with SMTP id 98e67ed59e1d1-2cf2e9cfe3fmr4274462a91.4.1721953135117; Thu, 25 Jul 2024 17:18:55 -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 18:18:43 -0600 Message-ID: Subject: Re: Towards __deprecated in cdefs.h To: Brooks Davis Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000f06c21061e1b7489" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1032:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4WVSzP0d9zz4fb9 --000000000000f06c21061e1b7489 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2024 at 5:57=E2=80=AFPM Warner Losh wrote: > > > On Thu, Jul 25, 2024 at 3:12=E2=80=AFPM Brooks Davis = 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. I= t >> > 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 thi= ng >> 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 --000000000000f06c21061e1b7489 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 25, 2024 at 5:57=E2=80=AF= PM Warner Losh <imp@bsdimp.com>= wrote:


On Thu, Jul 25, 2024 at 3:12=E2=80=AFPM Brook= s 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 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.freebs= d.org/D46144
and=C2=A0https://reviews.freebsd.org/D46145 so we shar= e the fixes... I haven't thought
about going the other direct= ion...=C2=A0 I'll have to see what that looks like.

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


--000000000000f06c21061e1b7489--