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]" |
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? > ahead, if no keep it private ;) Best regards, Bapt |
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]" |
In reply to this post by Baptiste Daroussin-2
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 ;) > it. Best regards, Kristof _______________________________________________ [hidden email] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "[hidden email]" |
In reply to this post by Li-Wen Hsu-3
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. > 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]" |
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]" |
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]" |
In reply to this post by Ryan Moeller
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: +1 415 225 5579 "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]" |
In reply to this post by Kristof Provost
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]" |
> 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]" |
In reply to this post by Mark Johnston-2
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]" |
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]" |
Free forum by Nabble | Edit this page |