ifnet/DrvAPI: Move if_t typedef to a better place

[jhibbits]

Summary

<net/if_var.h> should really be used by the netstack only, not by
drivers. Eventually all the accessors will be moved to <net/if.h> as
well, but for now just move the typedef while the KPI gets sorted and
drivers get converted.

Sponsored by: Juniper Networks, Inc.

[melifaro]

Q: What blockers prevent moving the accessors outside of if_var.h?
I'd actually spend some time removing if_var.h header from the inside the stack as well :-)

[jhibbits]

In D37784#860049, @melifaro wrote:

Q: What blockers prevent moving the accessors outside of if_var.h?

Nothing, really. Just doing this piecemeal. I noticed in some of my conversions that keeping the if_t typedef in if_var.h necessitated pulling it in where it wasn't needed beyond getting if_t, so pulled it out. The current users of struct ifnet beyond a forward declaration already include if_var.h so there's no gain or loss there.

I'd actually spend some time removing if_var.h header from the inside the stack as well :-)

Maybe later. Some people may have concerns about performance in the stack by using the accessors inside the stack, so save that for a later time.

[melifaro]

In D37784#860073, @jhibbits wrote:

In D37784#860049, @melifaro wrote:

Q: What blockers prevent moving the accessors outside of if_var.h?

Nothing, really. Just doing this piecemeal. I noticed in some of my conversions that keeping the if_t typedef in if_var.h necessitated pulling it in where it wasn't needed beyond getting if_t, so pulled it out. The current users of struct ifnet beyond a forward declaration already include if_var.h so there's no gain or loss there.

Got it, make sense. Do you have any tentative timeline in mind for the stage when these accessors can be moved outside if_var.h ?

I'd actually spend some time removing if_var.h header from the inside the stack as well :-)

Maybe later. Some people may have concerns about performance in the stack by using the accessors inside the stack, so save that for a later time.

SURE. I'm sorry for not being detailed enough.
Currently, if_var.h is used in ~270 files in the base (grep -RI if_var.h sys | grep -v sys/dev | wc -l). The performance argument is an absolutely valid one, but it affects ~10-15 files out of these 270.
What I meant was cleaning the remaining 200+ files. I wasn't suggesting you should do it - sorry if it read that way. That's something I have had on my list for quite some time.

[jhibbits]

In D37784#860171, @melifaro wrote:

In D37784#860073, @jhibbits wrote:

In D37784#860049, @melifaro wrote:

Q: What blockers prevent moving the accessors outside of if_var.h?

Nothing, really. Just doing this piecemeal. I noticed in some of my conversions that keeping the if_t typedef in if_var.h necessitated pulling it in where it wasn't needed beyond getting if_t, so pulled it out. The current users of struct ifnet beyond a forward declaration already include if_var.h so there's no gain or loss there.

Got it, make sense. Do you have any tentative timeline in mind for the stage when these accessors can be moved outside if_var.h ?

Once all the drivers are converted over, so hoping to have it all done by end of January. I've got a work in progress, but tons of build failures. Seems drivers love to include in_var.h, in6_var.h, etc. Those will be hard to pull out, so will take some time.

[melifaro]

In D37784#860268, @jhibbits wrote:

In D37784#860171, @melifaro wrote:

In D37784#860073, @jhibbits wrote:

In D37784#860049, @melifaro wrote:

Q: What blockers prevent moving the accessors outside of if_var.h?

Nothing, really. Just doing this piecemeal. I noticed in some of my conversions that keeping the if_t typedef in if_var.h necessitated pulling it in where it wasn't needed beyond getting if_t, so pulled it out. The current users of struct ifnet beyond a forward declaration already include if_var.h so there's no gain or loss there.

Got it, make sense. Do you have any tentative timeline in mind for the stage when these accessors can be moved outside if_var.h ?

Once all the drivers are converted over, so hoping to have it all done by end of January. I've got a work in progress, but tons of build failures. Seems drivers love to include in_var.h, in6_var.h, etc. Those will be hard to pull out, so will take some time.

Thank you for the clarification! No rush, just wanted to ensure we are on the same page w.r.t. reducing if_var.h header usage.