Date: Sun, 4 Sep 2022 08:09:53 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: Header symbols that shouldn't be visible to ports? Message-ID: <YxQzIf/xmwqz1Sn1@kib.kiev.ua> In-Reply-To: <CAOtMX2h_=6AXYDSZNF77qQH9fF1gsJKuDP%2BM3dD%2Bq6Xw97bHmg@mail.gmail.com> References: <CAOtMX2h_=6AXYDSZNF77qQH9fF1gsJKuDP%2BM3dD%2Bq6Xw97bHmg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YxQzIf/xmwqz1Sn1>