libifconfig non-private in 13?

[Mark Johnston]

On Tue, Jan 12, 2021 at 07:50:45PM +0100, Kristof Provost wrote:
> 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.

I posted a review to add a symbol map at least:
https://reviews.freebsd.org/D28119