Prepare for network stack as a module: ioctl group handling

[stevek]

Summary

Prepare for network stack as a module:

• Add generic socket ioctl group (iocgroup) handling
  • Allows for registering a group with the socket layer instead of needing network stack-specific code in generic socket code
  • iocgroups are handled similar to domains (all iocgroups must be registered before finalization - to avoid requiring additional locking to get pushed into a number of places in the kernel)
• Register interface iocgroup ('i')
  • Moves call to ifioctl into the soiocg_ioctl member of iocgroup structure
• Register router iocgroup ('r')
  • Moves call to rtiocl_fib to new function rtioctl_socket, which is the soiocg_ioctl member of the iocgroup structure

Obtained from: Juniper Networks, Inc.

Test Plan

Build LINT and LINT-NOIP
Tested with build of GENERIC and RPI2 images

[jtl]

See inline comments.

sys/kern/sys_socket.c

135

I think there should be a check for duplicate group identifiers.

152

Why is this either/or code? One is active with INVARIANTS, the other would be active without INVARIANTS. Both seem useful.

318

I believe style(9) requires comparison to NULL.

322

I believe style(9) requires comparison to NULL.

sys/sys/socketvar.h

140

I'm curious why you chose to concatenate the names directly, instead of adding an underscore (e.g. rtiocgroup instead of rt_iocgroup). I think I prefer having an underscore as a separator between the user-supplied and macro-supplied part, but I am curious if there is a good reason to do it the other way.

[stevek]

sys/kern/sys_socket.c

135

Probably would be a good idea, yes. Note this code is a direct lift of the protocol domain registration, so that should get some appropriate additions as well, in that case. See sys/kern/uipc_domain.c, specifically domain_add

152

Once again, direct lift of the protocol domain registration code.

318

Sure, I can update that. (Probably a lot of places within the kernel code that should get updated to do that.)

322

Same here, can update this.

sys/sys/socketvar.h

140

Because I had used the protocol domain registration as a starting point and that's the convention that was used there. So no good reason other than that.

[stevek]

I'm looking into handling the registration differently to avoid the finalization step in order to get closer to what is necessary to support loading/unloading modules. Therefore, marking this review with Plan Changes for now.