> But using SIOCAIFADDR/SIOCDIFADDR seems rather awkward since in_control() > requires a 'struct socket *so' argument (even though it does nothing with > it, except checking 'so->so_state & SS_PRIV'). Creating a socket inside > the driver for this sole purpose seems just as weird as setting up a > fake struct socket. > > Are you really sure, this is the better way to go?
No. This particular layer violation does not belong inside this driver. Instead, the driver should probably generate a route socket message, and then something on the outside would cause that effect of configuring addresses, routes, etc etc. But anyways, this conversation is not getting any code commited. The driver -- minus the contentious bits -- should be be shown, in just good enough form to compile. Then the contentious bits can be argued about and worked on together as a team...
