Re: [PATCH net-next] sockopt: Introduce the SO_BINDTOIFINDEX

[Brian Haley <brian.haley@hp.com>]

On 10/23/2012 01:36 PM, David Miller wrote:
> 
> This is really a huge ball of confusion.
> 
> The user asks for a device to bind to, and they want the device which
> had a particular name at the time of the call.
> 
> If you allow setting this via ifindex, the issues and races are the
> same whether the name-->ifindex translation is done before the
> sockopt() call or during it.

Yes, there are race conditions in the socket APIs, even IP addresses can go away
right before a bind() call.

> Furthermore both the name and the ifindex can change (that latter
> via module unload/load).
> 
> If you want me to consider these changes seriously, talk less about
> obtuse issues like symmetry and more about what problems it actually
> solves.  As far as I can tell, all the same real issues still exist
> even if we had this new interface.

Noone's complained about not having this getsockopt() for over 7+ years, so in
that sense I'm not sure what problem it solved adding it.

> In fact, I wouldn't mind if a getsockopt() on SO_BINDTODEVICE returned
> BOTH the name and the ifindex in a special structure.  Then you could
> actually construct a more foolproof mechanism on the user side to try
> various ways to get the same device bound to during restart.

There is no fool-proof way to do any of this since we can agree device names and
indexes can change.  But people aren't typically running daemons listening on
interfaces that are constantly changing like taps or tunnels, instead it's on
eth1 so they can run a private DHCP server.

> Symmetry is over-rated.

If any of the other SO_* options didn't set and get using the same structure I'd
agree with you, but I can't find any that do.

-Brian