From nobody Fri Jul 26 02:35:11 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 4WVX0k4CJ5z5RpBF for ; Fri, 26 Jul 2024 02:35:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WVX0k3gSsz4qG9; Fri, 26 Jul 2024 02:35:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721961318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6m9ucngEJ4F7wCAG4fQDIO6JqSUYprGkingNfNij1Vs=; b=MLBfRi3zper9DvRiIc/Z8l7dfnlN1FJbuIRCC47QzfflvlFunooC5Q6js8cMtT6cfUVW8W REplLHs9aZqvHVmYNwUm2ck5Nq3Xy6in1MVAr1HXDgpDqSI/ZnsnQMlrSl5Z+fyujOPKeZ C+6nYL7XacYIrBGRxOEJsyW68a3660NuPoQiJOEvDlfTXP7C6csznCYFgRD8/Oip/asRjE xPY81bgeaImszXBY/CnCy1lcnSFMVvIFhp+WVqS8AjpzliXEWqhfdCf3YmXVmFVXs6mdLc cROlwmM+C/9Xkt7Br4tRx/SPD0nB0StyOQJzQ6eV95kYY+ZWpprP+FFSc1sf3Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1721961318; a=rsa-sha256; cv=none; b=kmt9f3CGM36xvqN23kIQAalxCZbZ0RG+l9vTMU6A3eFqpwqfq7IQZ/u6Sma+7ozN9QXY24 YPHf/iczNzPIIHoHDvCAL1pyvRaa1s5t4O+hVF6Uda2Op0dxw6Aex3BjnbiE+LTkebmPLa ADrwfsD9a1fe6YFZSejk4gmN8EQrxoNcw9HyXLcz2rKChUDj+O3e9Os5TY4+N3MVjBn/rs YN/mbgQnrJ93AjH5BgGDHS6YRNCBEdAQ7wu97UtEhXOXfMhphxy0QpJOwD6GKX5G8Lm6zu nuNgpsTWjSMhb/C8CQAll+zNmPyI3O1Apybq0cVnoYoZOBWZLBdZdOjnid1Zig== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1721961318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6m9ucngEJ4F7wCAG4fQDIO6JqSUYprGkingNfNij1Vs=; b=m6ZfyO04Ue3VgSQsQvt8InXneuHz2yb5LhD4O58VzkO47sC7h55hrBiNnoeQYoqOU6jOkP V9N6MUfqjc8iLITXvf8PvLuyE+eB8DsLUoPuSWb9fm1uJtyobdBHVsvQuVRxOTfW9Mh4aY u7PHVewRCG9ddJG7xwTnqv9J2IzYUTRraJ7cGxQ6rL1y46KMi8PUiNdld4qtdWN0p44wC2 KswVF4R7PRpdQxrBxGQb6Hgfz/Ors5RjRn8aMGqFyX25WRD49VKpAI2XxdwCFAOMdIL4/Z J9VYHBrD56hVUYNbXyMnalXNxGC49r22aqW5sBw+M/bJ6HnZoKPkjDybiGoJTw== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WVX0j4jYdzQ19; Fri, 26 Jul 2024 02:35:17 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <4480E3AA-106D-40C3-84FF-7C6A11EC2649@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_A862F5E1-790E-42D9-A69C-69C558690610" 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 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: Towards __deprecated in cdefs.h Date: Fri, 26 Jul 2024 10:35:11 +0800 In-Reply-To: Cc: "freebsd-arch@freebsd.org" To: Warner Losh References: X-Mailer: Apple Mail (2.3696.120.41.1.8) --Apple-Mail=_A862F5E1-790E-42D9-A69C-69C558690610 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 26, 2024, at 3:41 AM, Warner Losh wrote: >=20 > There's often times we want to mark interfaces as allowed, but please = stop using it. Also the userland libraries have some interfaces commented or documented = deprecated but persist for quite long time. It would be nice to have compiler warnings for the usage so we could = evolve fast. >=20 > C23 has a new, fancy [[deprecated]] and [[deprecated("msg")]] forms. = It would be nice to start using it. >=20 > The question is how. >=20 > 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. Yes. Too many warnings to be useful. I doubt if we can emit the warning for changed or new code only. I think = it would be nice to have CI to do that. A typical usage should be = pre-commit checks. Turn on flag of deprecated warnings only for the = changed files and filter out the changed lines. For existing code, if the migration is desired, developer could turn on = the flag manually to verify his / her work. >=20 > So position [1] is to do what Linux did. Make iit a #define that does = nothing. >=20 > Position [2] is do what Linux did originally: make it a warning to use = deprecated interfaces (but likely a -Wno-error warning). >=20 > 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]. >=20 > 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]. I think it is useful to always have a message to explain why and to = direct an alternative . >=20 > There's likely more crazy, but that's likely too crazy to contemplate. >=20 > Personally, I think that option [4] is best: have __deprecated and = __deprecated_msg(x), both of which always warn. >=20 > 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. No. Technically not. It would always be bypassed if intended. Why not = turn __deprecated_error into ERROR or drop that definition ? If deprecations would globally be turned to errors, the proper approach = should a condition, either a macro, or compiler flag. >=20 > 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. >=20 > 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 = >=20 > Warner Best regards, Zhenlei --Apple-Mail=_A862F5E1-790E-42D9-A69C-69C558690610 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jul 26, 2024, at 3:41 AM, Warner Losh <imp@bsdimp.com> = wrote:

There's often times we want to mark = interfaces as allowed, but please stop using = it.

Also the = userland libraries have some interfaces commented or documented = deprecated but persist for quite long time.
It would be nice = to have compiler warnings for the usage so we could evolve = fast.

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.

Yes. = Too many warnings to be useful.

I = doubt if we can emit the warning for changed or new code only. I think = it would be nice to have CI to do that. A typical usage should be = pre-commit checks. Turn on flag of deprecated warnings only for the changed files and filter out the = changed lines.

For existing code, if the migration is = desired, developer could turn on the flag manually to verify his / her = work.

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].

I = think it is useful to always have a message to explain why and to direct = an alternative .

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.

No. Technically not. It would always be bypassed = if intended. Why not turn __deprecated_error into ERROR or drop = that definition ?

If deprecations = would globally be turned to errors, the proper approach should a = condition, either a macro, or compiler flag.


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

Best regards,
Zhenlei

= --Apple-Mail=_A862F5E1-790E-42D9-A69C-69C558690610--