Date: Tue, 12 Jan 2021 13:48:42 -0500 From: Daniel Eischen <deischen@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: Kristof Provost <kp@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: libifconfig non-private in 13? Message-ID: <9CA63E1A-C206-4FF3-9B29-DB630D06D4A7@freebsd.org> In-Reply-To: <X/3eCk7gj6broQYt@raichu> References: <X/3eCk7gj6broQYt@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 12, 2021, at 12:37 PM, Mark Johnston <markj@freebsd.org> wrote: >=20 > =EF=BB=BFOn Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote: >> Hi, >>=20 >> Libifconfig was marked as private (and experimental) back in 2016. >> It=E2=80=99s since made some strides and has grown a few users. Ifconfig n= ow=20 >> depends on it as well. >>=20 >> While it=E2=80=99s far from finished it=E2=80=99d be more useful for some= users if=20 >> it were public. That would at least imply some level of API/ABI=20 >> stability, which is why I=E2=80=99m bringing it up here before pulling th= e=20 >> trigger. >>=20 >> Does anyone see any reasons to not do this? >=20 > I note that libifconfig doesn't version its symbols. In other words, > compatibility-breaking changes generally require a shlib version bump, > which will be painful for out-of-tree consumers (and if we don't expect > to have such consumers there's no reason to make it a public library). > Symbol versioning isn't perfect but makes some kinds of breaking changes > easier to handle, and might be worthwhile here since I'd expect > libifconfig to keep evolving for a while. Should we add a symbol map > ahead of making libifconfig public? Perhaps there are exceptions, but I would suggest that any new base library b= eing made public provide versioned symbols. -- DE=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9CA63E1A-C206-4FF3-9B29-DB630D06D4A7>