libifconfig non-private in 13?

John-Mark Gurney jmg at funkthat.com
Tue Jan 12 06:51:34 UTC 2021


Ryan Moeller wrote this message on Tue, Jan 05, 2021 at 13:56 -0500:
> On Sun, Dec 27, 2020 at 9:15 AM Kristof Provost <kp at freebsd.org> wrote:
> >
> > On 26 Dec 2020, at 22:33, Li-Wen Hsu wrote:
> > > On Sun, Dec 27, 2020 at 5:18 AM Baptiste Daroussin <bapt at freebsd.org>
> > > 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 agree with the feeling that the current API may eventually need to be revised,
> but as far as I'm aware nobody has plans or work in progress on that front.
> I don't object to making the library public, and perhaps that will even help
> gather interested parties to help continue fleshing out the missing pieces.
> 
> > >>
> > >> I would go the otherway around, any reason to make it public yet? if
> > >> yes they go
> > >> ahead, if no keep it private ;)
> > >
> > > I would say it is nice to have some scripting language bindings to it,
> > > although I'm not sure if this is possible and a feasible usage.
> > >
> > I???m sure it???s possible. Ryan actually done some of that work:
> > https://reviews.freebsd.org/D25447
> >
> > Maybe we should merge that too.
> 
> The API does make bindings a little funky, but it works.
> 
> I recall speaking to at least one person who was interested in Python bindings
> for libifconfig, as well.

I currently would like to use libifconfig, but I'm worried that it's
undocumented.  There are no man pages to help guide a user.  IMO, it
shouldn't be made public till there is decent documentation for it.

The lua bindings has docs, but I haven't looked at them in detailed
to see if they could be adapted to the C api at all..

I'd be more than willing to [help] maintain a ctypes based ifconfig
binding for Python.  These are often pretty quick to get together..

> My only plans for the time being are to continue moving functionality
> from ifconfig
> into libifconfig little by little, but it's an "if and when I feel
> like it" low priority kind of thing.
> As I do this I will continue to keep the flua library updated as well.
> 
> If memory serves, I have everything currently in libifconfig
> implemented in the flua library
> and roughly documented in the ifconfig(3lua) manual page, but that
> isn't a whole lot.
> A ton of useful/important ifconfig features are not yet implemented in
> libifconfig.
> Still, it's better than nothing even in the current state. Most of the
> basic useful getters
> are there, at least. Not much is there in the way of setters.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."


More information about the freebsd-arch mailing list