libifconfig non-private in 13?

[Kristof Provost]

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?

Regards,
Kristof
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Baptiste Daroussin-2]

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 would go the otherway around, any reason to make it public yet? if yes they go
ahead, if no keep it private ;)

Best regards,
Bapt

[Li-Wen Hsu-3]

On Sun, Dec 27, 2020 at 5:18 AM Baptiste Daroussin <[hidden email]> 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 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.

Best,
Li-Wen
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Kristof Provost]

On 26 Dec 2020, at 22:18, Baptiste Daroussin 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 would go the otherway around, any reason to make it public yet? if
> yes they go
> ahead, if no keep it private ;)
>

Well, I did ask because there’s at least one potential user asking for
it.

Best regards,
Kristof
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Kristof Provost]

On 26 Dec 2020, at 22:33, Li-Wen Hsu wrote:

> On Sun, Dec 27, 2020 at 5:18 AM Baptiste Daroussin <[hidden email]>
> 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 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.

Best regards,
Kristof
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Ryan Moeller]

On Sun, Dec 27, 2020 at 9:15 AM Kristof Provost <[hidden email]> wrote:

>
> On 26 Dec 2020, at 22:33, Li-Wen Hsu wrote:
> > On Sun, Dec 27, 2020 at 5:18 AM Baptiste Daroussin <[hidden email]>
> > 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.

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.

--
Ryan Moeller
iXsystems, Inc.
OS Developer
Email: [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Dave Cottlehuber-2]

On Tue, 5 Jan 2021, at 18:56, Ryan Moeller 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.
...
> > I’m sure it’s possible. Ryan actually done some of that work:
> > https://reviews.freebsd.org/D25447
> >
> > Maybe we should merge that too.

yes & yes - both of these would be great additions & steps in the right direction.

A+
Dave
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[John-Mark Gurney-2]

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 <[hidden email]> wrote:
> >
> > On 26 Dec 2020, at 22:33, Li-Wen Hsu wrote:
> > > On Sun, Dec 27, 2020 at 5:18 AM Baptiste Daroussin <[hidden email]>
> > > 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: [phone]

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Mark Johnston-2]

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?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Daniel Eischen]

> On Jan 12, 2021, at 12:37 PM, Mark Johnston <[hidden email]> 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?

Perhaps there are exceptions, but I would suggest that any new base library being made public provide versioned symbols.

--
DE
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Kristof Provost]

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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Mark Johnston-2]

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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"