Page MenuHomeFreeBSD

ifnet/DrvAPI: Move if_t typedef to a better place
ClosedPublic

Authored by jhibbits on Dec 22 2022, 3:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Jul 17, 10:12 PM
Unknown Object (File)
May 17 2024, 11:45 AM
Unknown Object (File)
May 4 2024, 12:21 AM
Unknown Object (File)
May 4 2024, 12:21 AM
Unknown Object (File)
May 4 2024, 12:21 AM
Unknown Object (File)
May 3 2024, 11:16 PM
Unknown Object (File)
May 2 2024, 7:19 PM
Unknown Object (File)
Apr 26 2024, 2:16 PM

Details

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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

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 :-)

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.

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.

This revision is now accepted and ready to land.Dec 23 2022, 2:05 PM

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.

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.