From nobody Thu Jul 25 19:41:06 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 4WVLq50LSvz5R9Hk for ; Thu, 25 Jul 2024 19:41:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 4WVLq40jH4z42w1 for ; Thu, 25 Jul 2024 19:41:20 +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=HNwNTiYE; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102e) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2cb55418470so165929a91.1 for ; Thu, 25 Jul 2024 12:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721936478; x=1722541278; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3qmU6tmToMmrhV/YRZ1fuGs6bGjrVhCSQNtXTQDYPtE=; b=HNwNTiYEDkxFbMFexHqlaBTVe1Wd9WmK4iUNoA6KFyxjTshqJn8bEuKXjPbgyaRlZd Sk55nauFJCr9ppZOAy72IL8u8V7cpPwUNrSyG0edbBsSboCflfcwzqHjiOW5AZkoLGi/ lUpLW4l1g+EaH6rffY9+/E8KmJSd8mY08U7vpxfxTrdbg8V84lcUc66JQFZd5G8arou0 mj4XvLjrf9mnTpe17QLueCKWh72X+gwkV7pUtYmeVCIr6J7Q8Iu+g744CSHazZnaxhiH 3nY16ioQzYSz+fCi/r7SspgomSe0D5/7LhVkTl7mU/CWeBkJdKsFb/WKrlNl7QrrWRNA TUag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721936478; x=1722541278; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3qmU6tmToMmrhV/YRZ1fuGs6bGjrVhCSQNtXTQDYPtE=; b=bXYdi9cC2yo++ngy5FjAcsxWtnbVL+Chl0VeM4u5qskdpZSUs5NbQQSDYo6fjse7nn Yc7T+dYJph3WZfkzUX4nxt3hinc6IkJNUfNXmk0Ir25QFADPTuLJhnqXWhwItgHQFBoz GMYN74xTf/ivP2Z8cxmC+c69bcmxIxGRQtuDoTh/Bbd5jGf5RMNj8di7DG80AQZqJrzq vnmu14YzS3tjyzcQd2/R5GnoIx2aB3sUTAMoroXfXUI27hd74Eh0qWqW+32Ifg8xLvMF 9jQv7TUavKACt8ybPA65WPh1qyB8meZu/CVYyQ8K0toAX3bG8Q4OeO9fLxtnNEPrMCN4 YMrQ== X-Gm-Message-State: AOJu0YwNJabOarBJBYFMNUUKxRr6wAHWOY3m7HAvJ612DmPDfEdkAo3B zVh5kZRnqTR6s4u5UCuGNP7jgUmdkO3ZF6Cim3HOhwSUMa5ELtiBLr2mS7o4hgQjcr3MGnRRnuY wTlSjwMw/Flx+dbXjpB4bPe5UyDTRdO8twaXgd6362oKLQKQLuuMyvA== X-Google-Smtp-Source: AGHT+IFLaYNZRxKpgVMsLmeZF0HCFREQD3IP0nSe1iZH3bS4WtBGxGQL57+41H8A50ayvEYY2fqU91hM8GTd+Hn2IdM= X-Received: by 2002:a17:90a:b118:b0:2c6:ee50:5af4 with SMTP id 98e67ed59e1d1-2cf2e9ab0b7mr3233820a91.6.1721936477806; Thu, 25 Jul 2024 12:41:17 -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 From: Warner Losh Date: Thu, 25 Jul 2024 13:41:06 -0600 Message-ID: Subject: Towards __deprecated in cdefs.h To: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000160092061e17946f" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; 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]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102e:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4WVLq40jH4z42w1 --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
There's often times we want to mark interfaces=C2=A0as= 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=C2=A0because too many warnings were thrown during a kern= el 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 inte= rfaces (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 param= eterized replacement, but never both. So, we'd need
__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].

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>
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 wa= rn.

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.

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=A0https://reviews.freebsd.org/D46137 a= nd the ensuing conversation in IRC didn't have 'no-brainer yes'= written all over it.

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=A0https://github.com/openzfs/zfs/pull/16388
=

Warner
--000000000000160092061e17946f--