From nobody Sun Sep 04 05:09:53 2022 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 4ML08B6cfNz4bSTb for ; Sun, 4 Sep 2022 05:10:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ML0894WZtz3k5Y; Sun, 4 Sep 2022 05:10:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 28459rPI020140 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 4 Sep 2022 08:09:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 28459rUC020139; Sun, 4 Sep 2022 08:09:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 Sep 2022 08:09:53 +0300 From: Konstantin Belousov To: Alan Somers Cc: FreeBSD CURRENT Subject: Re: Header symbols that shouldn't be visible to ports? Message-ID: References: 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home X-Rspamd-Queue-Id: 4ML0894WZtz3k5Y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.92 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; NEURAL_HAM_SHORT(-0.94)[-0.937]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote: > Our /usr/include headers define a lot of symbols that are used by > critical utilities in the base system like ps and ifconfig, but aren't > stable across major releases. Since they aren't stable, utilities > built for older releases won't run correctly on newer ones. Would it > make sense to guard these symbols so they can't be used by programs in > the ports tree? There is some precedent for that, for example > _WANT_SOCKET and _WANT_MNTOPTNAMES. _WANT_SOCKET is clearly about exposing parts of the kernel definitions for userspace code that wants to dig into kernel structures. Similarly for _WANT_MNTOPTNAMES, but in fact this thing is quite stable. The definitions are guarded by additional defines not due to their instability, but because using them in userspace requires (much) more preparation from userspace environment, which is either not trivial (_WANT_SOCKET) or contradicts to standartized use of the header (_WANT_MNTOPTNAMES + sys/mount.h). > > I'm particular, I'm thinking about symbols like the following: > MINCORE_SUPER Why this symbol should be hidden? It is implementation-defined and intended to be exposed to userspace. All MINCORE_* not only MINCORE_SUPER are under BSD_VISIBLE braces, because POSIX does not define the symbols. > TDF_* These symbols coming from non-standard header sys/proc.h. If userspace includes the header, it is already outside any formal standard, and I do not see a reason to make the implementation more convoluted there. > PRI_MAX* > PRI_MIN* > PI_*, PRIBIO, PVFS, etc > IFCAP_* These are all implementation-specific and come from non-standard headers, unless I am mistaken, then please correct me. > RLIM_NLIMITS > IFF_* Same. > *_MAXID This is too broad. > > Clearly delineating private symbols like this would ease the > maintenance burden on languages that rely on FFI, like Ruby and Rust. > FFI basically assumes that symbols once defined will never change. Why e.g. sys/proc.h is ever consumed by FFI wrappers?