From nobody Fri Dec 03 13:30:01 2021 X-Original-To: freebsd-current@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 6961118C0D77 for ; Fri, 3 Dec 2021 13:30:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5DG32B4Sz4ZKc for ; Fri, 3 Dec 2021 13:30:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x72e.google.com with SMTP id g28so3315800qkk.9 for ; Fri, 03 Dec 2021 05:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UXnNtonbFkc78oPg5dPDRrqYFKoMq+gzkjEXdMC0f3c=; b=BDeJYCrEom4WWIzO20OboAE9+EFbUhvx5rvyxTyejLk0wOq0epDEfyNRUF39RLyTBv ZC+S6RJMoo/CfnfIibZa7uNwaVUH8HNfMHK7LsHsr/V3PaLJAWFCiPHsqCp3lMB6ZhF3 UvQEoYzZoCFDg+ooObPk66ReoR/zPYWBVShcA7qtuvJ/WYWp/cbTO6Lhi9Wc2Ov0e14C 1/L+ZsxlF5+i3B6CssMmrB7BCsoqi82EbGT/RprX77IQuG+TxdMOSrpZeVb3DdbH7dWz z83AnZZxivypGUiYEe2m9naJfoo6KSWQ/DLJS5nE04o1EVvmeIeSsu/KioEPBrNyn3JO FuDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UXnNtonbFkc78oPg5dPDRrqYFKoMq+gzkjEXdMC0f3c=; b=qxHD6/eDDgsSDr4zRjINK5+ayYLvX9B8COrMsvJikz0UoxtQKgp91oxMf36JXfci3Y zhERwgoKPN4qgnqsfAjLAbLpa5O9lUMLlu1J+fUoG5kn//lQQ6H+OhLvC4zmlpxFfn1B IQjf4h9Qg0gpMoyE2ymhzwpDGA8Nh0BMeWVuaxku4X8YouL8tOQqaUA+glVuFQyk+z39 m7Zd9T0kJn772eVkWujMNew1GXgZlXIYl0YLExkLaSSLVl/9wpubN/RI28phF5K6mFZW lG/oxR5YcknWvovBVHtY+A9xgZedTqIhcCbpmgYAmHeDXgCtPFZqcLWu+sh263zQdxyX 5GRQ== X-Gm-Message-State: AOAM5304V+9ZIhGgCKQVnSdruAdaT66ZSv8A0aU2q6+jKzcJFnfiN/J8 aFEqUu0hpZL6G6zWFhqp6Smj3Ag/9fBrDSOO X-Google-Smtp-Source: ABdhPJwG9thu5vEuHQLp2uvMKRMAe+NeS5CM5HTda96fMwRDNUPrkNz3Bygu8rt7iinKGL6k9qLpVA== X-Received: by 2002:a05:620a:248a:: with SMTP id i10mr17252350qkn.554.1638538202756; Fri, 03 Dec 2021 05:30:02 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id t11sm1935997qkm.96.2021.12.03.05.30.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Dec 2021 05:30:02 -0800 (PST) Date: Fri, 3 Dec 2021 08:30:01 -0500 From: Shawn Webb To: Stefan Esser Cc: FreeBSD CURRENT Subject: Re: [REVIEW] Hide BIT_* macros from userland code Message-ID: <20211203133001.scaxfsnjy7voast6@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <7d97e129-4aa7-aa98-dc91-e332a3da620f@freebsd.org> <20211202164648.276kuh3blin6b2wp@mutt-hbsd> <77845d03-6351-8a8b-2eae-1db98f8a192c@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qymcuzu56lw4m24j" Content-Disposition: inline In-Reply-To: <77845d03-6351-8a8b-2eae-1db98f8a192c@freebsd.org> X-Rspamd-Queue-Id: 4J5DG32B4Sz4ZKc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --qymcuzu56lw4m24j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 03, 2021 at 11:03:54AM +0100, Stefan Esser wrote: > Am 02.12.21 um 17:46 schrieb Shawn Webb: > > Hey Stefan, > >=20 > > On Thu, Dec 02, 2021 at 05:26:55PM +0100, Stefan Esser wrote: > >> I have created > >> > >> https://reviews.freebsd.org/D33235 > >> > >> to remove the BIT_* macros used in the kernel from the userland API. > >> > >> They conflict with differing definitions in some 3rd party code and > >> lead to compile issues in a number of ports (via CPU_* macros based > >> on the BIT_* macros). > >> > >> See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259787 > >> for an example of such a problem. > >=20 > > I recently was in a position to evaluate BIT_* macros for userland > > use. It was around the time when the conversation regarding hiding > > BIT_* from userland, which conversation caused me to find another > > solution. > >=20 > > I think such an API is incredibly useful, so I wonder if there's a way > > to satisfy both. For example, maybe prefix the userland side with a > > USERLAND_ or something similar? Kernel would use BIT_* and userland > > would use USERLAND_BIT_* (just spitballing, not actually advocating > > for "USERLAND_BIT_*" but rather just the idea of it.) >=20 > Hi Shawn, >=20 > I have updated the patch set in review D33235 and have added you to > the reviewer list. >=20 > IMHO the approach proposed by Konstantin Belousov is better than the > introduction of prefixed macro names for the userland. >=20 > A simple #define _WANT_FREEBSD_BITSET makes the __BIT* macros available > by their traditional names, no other changes are required in the code. >=20 > This does not solve the potential case of a program that wants to use > both the BSD and GLIBC variants of the macros in a single source file. > But I think that such a case is constructed and does not occur in > actual code. >=20 > And in any case, the IMHO __BIT* names are as good as the USERLAND_BIT* > names you suggest (and I understand that you did not want that specific > name - therefore a prefix of __ might be considered to match what you > proposed ;-) ). >=20 > And you are of course free to map __BIT* to any other prefixed name in > a header file in your code ... >=20 > An update of the bitset(9) man page might be a good idea, explaining > the visibility rules and _WANT_FREEBSD_BITSET for system utilities that > need to work with kernel style bitsets. Awesome. kib's suggestion makes sense here. And thanks for adding me to the review. I'll make sure to pay attention as it progresses. :-) Thanks again, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --qymcuzu56lw4m24j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGqG9kACgkQ/y5nonf4 4fo+vA/7B48h4Dk5YDfATIpbnQEb7yDPSpLDjJxRwKijpsE+QfLQXHzXpXybMfxB 6xlHdCC+O1XnoQwMy8A/ZCulvNtRT+0l70cElhuXNiay/KHF7Q1XGYpFvOd01FRK qP9QC8s+lFehyn30kzdDChqegN9OPLwz9u6miQmX5qLyb0KSzJjFSA31mNPF8Fqy aMUmAiSWuR52AMgkpuR2lNTIzxDf7VrE+wFutoVXVG0OYxfzh4tst6zuzG/Tc4fh HbcS8gjuVq8jv5nCbYXa4umdXfLCzvt4kHLh7GUpTpx/ZuBUF6ClIQfiZE6llS/4 zVRAEasWuAOwIc6C/BT2/ZuEpfXohP1bqwrVnCexexYIVySh7I2y6+udMFnLwt73 vxHrtTwhbZeTGRHYvvglO3Jj7cRY1Q7bdM6Uih/Rc1HTKFIG/7p7ARdMY1nkr+VH lxBSLPdATOCSS1NYlTXzvRwk8oQACorBqQmqoB2p9+YclJoIEtb+JiZPYTQvXBQL ujWjT0ebc4ZRZoGLAp92rgGuPGGmsi4mHx13yXSlew7K8hXhJjeCC71/JWMnGM5h moDuetLnjJ8uwM5/oRVyigyA641gJb3lwMjYezfCiBKTwTBUKvJwD1kRjZY6r7Uv eWZoeRLKvGb0w+EppNXCmZEzJxOZtCLfuAyCthwSyMlVvUPTDic= =KuU3 -----END PGP SIGNATURE----- --qymcuzu56lw4m24j--