Date: Tue, 12 Jan 2021 19:50:45 +0100 From: "Kristof Provost" <kp@FreeBSD.org> To: "Mark Johnston" <markj@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: libifconfig non-private in 13? Message-ID: <51DB9AE6-66F8-43A8-8B47-07E3441CBC29@FreeBSD.org> In-Reply-To: <X/3eCk7gj6broQYt@raichu> References: <1EB6D7ED-F370-42EA-AC66-93D8BC96F29C@FreeBSD.org> <X/3eCk7gj6broQYt@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Jan 2021, at 18:36, Mark Johnston wrote: > On Mon, Dec 21, 2020 at 09:02:00PM +0100, Kristof Provost wrote: >> Hi, >> >> Libifconfig was marked as private (and experimental) back in 2016. >> It’s since made some strides and has grown a few users. Ifconfig >> now >> depends on it as well. >> >> While it’s far from finished it’d be more useful for some users >> if >> it were public. That would at least imply some level of API/ABI >> stability, which is why I’m bringing it up here before pulling the >> trigger. >> >> Does anyone see any reasons to not do this? > > 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? Yes, we should to that, as well as write up a man page for the current API. I did make a start on the man page a while back, but spare time has been hard to come by. Best regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51DB9AE6-66F8-43A8-8B47-07E3441CBC29>