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
--00000000000000a82c064014a3b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Kristof Provost <kp@freebsd.org> wro= te: > 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 i= n > struct > > K> > ifnet, a function to access it shall exist? > > K> > > > K> It=E2=80=99s 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 wa= s > 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=E2=80=99s always easier to think about these things with speci= fic > problems in mind. > > =E2=80=94 > Kristof > --00000000000000a82c064014a3b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><span style=3D"white-space-collapse: preserve;">Hello= ,</span></div><div dir=3D"ltr">Both emails are mine - one I use as my GitHu= b email and the one I signed off with is my personal email. Sorry for the c= onfusion there.<br><span style=3D"white-space-collapse: preserve;">To answe= r your questions:</span><br><span style=3D"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 str= uct ifnet, and to maintain consistency I added this one since it was missin= g.</span></div><div><span style=3D"white-space-collapse: preserve;">I'm= not aware of any drivers that need if_home_vnet and if_vmove</span></div><= div><span style=3D"white-space-collapse: preserve;">Regards,</span></div><d= iv><span style=3D"white-space-collapse: preserve;">Kevin.</span></div><div = dir=3D"ltr"><span style=3D"white-space-collapse: preserve;"><br></span></di= v><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cla= ss=3D"gmail_attr">On Wed, Oct 1, 2025 at 8:49=E2=80=AFAM Kristof Provost &l= t;<a href=3D"mailto:kp@freebsd.org">kp@freebsd.org</a>> wrote:<br></div>= <blockquote class=3D"gmail_quote" style=3D"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 reall= y needs to access<br> > K> > this field or was this added by the logic that if a field e= xists in struct<br> > K> > ifnet, a function to access it shall exist?<br> > K> ><br> > K> It=E2=80=99s hard to predict what fields will be relevant for ou= t-of-tree consumers, but it seems reasonable to allow access to this one gi= ven we already allow the current vnet to be accessed too.<br> ><br> > As we discussed earlier through the last decade, the ifnet is poorly d= esigned<br> > and we need a new API.=C2=A0 But as that was a heavy weight to lift, t= hat was never<br> > finished.=C2=A0 Juniper came with a plan to provide accessors.=C2=A0 T= hey would not make<br> > API any better or prettier, but would basically provide binary compati= bility<br> > for a case when struct ifnet grows or is rearranged but all existing f= ields<br> > remain! We agreed that this is an interim step towards a better API in= a<br> > future.=C2=A0 The Juniper's API shall provide access to minimal se= t of ifnet fields<br> > that current drivers use. It should not encourage use of fields that b= elong 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 d= o 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, bec= ause it=E2=80=99s always easier to think about these things with specific p= roblems in mind.<br> <br> =E2=80=94<br> Kristof<br> </blockquote></div></div> --00000000000000a82c064014a3b0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABmcMp0tgu161k71rdK8rgM-wzzFV-k-Nr_ccH78SwxA7gfaWw>