Re: git: 4e7a375804e5 - main - IfAPI: Added missing accessor for if_home_vnet

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