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 <k...@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 >
