Date: Wed, 1 Oct 2025 09:27:05 +0100 From: Kevin Irabor <kevin.irabor04@gmail.com> To: Kristof Provost <kp@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, ItzBlinkzy <kitey13579@gmail.com>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 4e7a375804e5 - main - IfAPI: Added missing accessor for if_home_vnet Message-ID: <CABmcMp0tgu161k71rdK8rgM-wzzFV-k-Nr_ccH78SwxA7gfaWw@mail.gmail.com> In-Reply-To: <D992AE7A-1BB5-4630-8A2E-35E0EA6B8782@FreeBSD.org> References: <202509292116.58TLGxWx078766@gitrepo.freebsd.org> <aNwVz6wL5cLbmYqR@cell.glebi.us> <9E63C594-08DD-43CD-BD76-3E9B9E80AA60@FreeBSD.org> <aNwdPbnDvkBA0mQ1@cell.glebi.us> <D992AE7A-1BB5-4630-8A2E-35E0EA6B8782@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Hello, Both emails are mine - one I use as my GitHub email and the one I signed off with is my personal email. Sorry for the confusion there. To answer your questions: I was browsing the ifnet code and saw the earlier IfAPI commits that were made. I assumed the pattern was to provide accessors for every field in struct ifnet, and to maintain consistency I added this one since it was missing. I'm not aware of any drivers that need if_home_vnet and if_vmove Regards, Kevin. On Wed, Oct 1, 2025 at 8:49 AM Kristof Provost <kp@freebsd.org> wrote: > On 30 Sep 2025, at 20:11, Gleb Smirnoff wrote: > > On Tue, Sep 30, 2025 at 07:51:05PM +0200, Kristof Provost wrote: > > K> > The actual question is whether there is a driver that really needs > to access > > K> > this field or was this added by the logic that if a field exists in > struct > > K> > ifnet, a function to access it shall exist? > > K> > > > K> It’s hard to predict what fields will be relevant for out-of-tree > consumers, but it seems reasonable to allow access to this one given we > already allow the current vnet to be accessed too. > > > > As we discussed earlier through the last decade, the ifnet is poorly > designed > > and we need a new API. But as that was a heavy weight to lift, that was > never > > finished. Juniper came with a plan to provide accessors. They would > not make > > API any better or prettier, but would basically provide binary > compatibility > > for a case when struct ifnet grows or is rearranged but all existing > fields > > remain! We agreed that this is an interim step towards a better API in a > > future. The Juniper's API shall provide access to minimal set of ifnet > fields > > that current drivers use. It should not encourage use of fields that > belong to > > the stack, not to the drivers. So, the question is what is the driver > that > > needs if_home_vnet? Who is maintaining it and what are they going to do > if I > > remove if_home_vnet together with if_vmove? > > > Good questions. I hope Kevin can tell us what his use case for this is, > because it’s always easier to think about these things with specific > problems in mind. > > — > Kristof > [-- Attachment #2 --] <div dir="ltr"><div><span style="white-space-collapse: preserve;">Hello,</span></div><div dir="ltr">Both emails are mine - one I use as my GitHub email and the one I signed off with is my personal email. Sorry for the confusion there.<br><span style="white-space-collapse: preserve;">To answer your questions:</span><br><span style="white-space-collapse: preserve;">I was browsing the ifnet code and saw the earlier IfAPI commits that were made. I assumed the pattern was to provide accessors for every field in struct ifnet, and to maintain consistency I added this one since it was missing.</span></div><div><span style="white-space-collapse: preserve;">I'm not aware of any drivers that need if_home_vnet and if_vmove</span></div><div><span style="white-space-collapse: preserve;">Regards,</span></div><div><span style="white-space-collapse: preserve;">Kevin.</span></div><div dir="ltr"><span style="white-space-collapse: preserve;"><br></span></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Oct 1, 2025 at 8:49 AM Kristof Provost <<a href="mailto:kp@freebsd.org">kp@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 30 Sep 2025, at 20:11, Gleb Smirnoff wrote:<br> > On Tue, Sep 30, 2025 at 07:51:05PM +0200, Kristof Provost wrote:<br> > K> > The actual question is whether there is a driver that really needs to access<br> > K> > this field or was this added by the logic that if a field exists in struct<br> > K> > ifnet, a function to access it shall exist?<br> > K> ><br> > K> It’s hard to predict what fields will be relevant for out-of-tree consumers, but it seems reasonable to allow access to this one given we already allow the current vnet to be accessed too.<br> ><br> > As we discussed earlier through the last decade, the ifnet is poorly designed<br> > and we need a new API. But as that was a heavy weight to lift, that was never<br> > finished. Juniper came with a plan to provide accessors. They would not make<br> > API any better or prettier, but would basically provide binary compatibility<br> > for a case when struct ifnet grows or is rearranged but all existing fields<br> > remain! We agreed that this is an interim step towards a better API in a<br> > future. The Juniper's API shall provide access to minimal set of ifnet fields<br> > that current drivers use. It should not encourage use of fields that belong to<br> > the stack, not to the drivers. So, the question is what is the driver that<br> > needs if_home_vnet? Who is maintaining it and what are they going to do if I<br> > remove if_home_vnet together with if_vmove?<br> ><br> Good questions. I hope Kevin can tell us what his use case for this is, because it’s always easier to think about these things with specific problems in mind.<br> <br> —<br> Kristof<br> </blockquote></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABmcMp0tgu161k71rdK8rgM-wzzFV-k-Nr_ccH78SwxA7gfaWw>