On Sat, Feb 04, 2017 at 11:28:08PM +0100, Uwe Kleine-König wrote: > On Sat, Feb 04, 2017 at 03:46:46PM +1030, Ron wrote: > > > [...] > > That would seem to be a pretty good summation of how we're failing to > > converge here ... > > I mixed too many things that IMHO improve the code but actually only > care about one of those. So I suggest we restart the discussion with > focusing on that one thing only.
Just repeating the same things, while ignoring the options I've shown you that do properly fix the problem(s) you're claiming to care about, isn't actually advancing this toward a workable solution in any way. My previous replies to you were already focussed on the part of your patch that removed AI_ADDRCONFIG, and why it was not needed at best, and harmful at worst. I can read the actual code, and understand how gai works, and I'm pretty sure Mike understood all of that too when he first reported this bug. I'd already long ago checked that there wasn't a real bug being triggered somewhere here, and that the code itself really was working as expected, and you haven't indicated anything to the contrary here. In the subset of cases where gai is used to resolve a string into a (set of) network address(es), it is not wrong to tell it that it's useless to return any address (family) which can't possibly work with the current machine configuration/state. That doesn't become less wrong if your expectation or interpretation of how it should work is different to reality and the specification of how it is defined to work. If you explicitly say "bind to 0.0.0.0", you're saying you want to service global IPv4 requests. If you have no global IPv4 interfaces, that should fail and warn the admin of a problem, not silently ignore that what they explicitly requested isn't going to work. If what you meant to request was "bind to whatever *is* there, I don't care what", then just don't pass an explicit address. If you're allergic to that possibly also binding to IPv6 addresses, then pass the -4 flag too. We don't need to disable the sanity check for users who do configure an explicit address for you to get the behaviour you say you want from the current code, without any change to it at all. If what you care about is "faster boot", then the answer to that isn't "speculatively start things that will fail (or just be useless) if they lose a race", it's to actually not waste time and resources doing that until their known prerequisites have been satisfied. Where it is expected that the available interfaces and/or configured addresses might change dynamically long after boot, then whatever you have doing that needs to notify, or reload, or (re)start, (or stop), anything you are or want to be (not) running, based on that new state of the system. If you want that, propose a patch to add a hook. Otherwise, what you say you want is already possible without needing the kludge you did send. The only bit I'm still struggling to understand, is why you are still pushing this patch hard instead of using what is already available that has exactly the behaviour you say you desire, or looking at a more complete and working solution for dynamic interfaces in general. The options here and the actions of the code don't look very complicated to me, so you don't need to "simplify" it on my behalf. I'm just not seeing you show any new problem that isn't contrived and that doesn't already have a good and/or already working solution which doesn't depend on needing this patch. What problem isn't satisfied by the options I've shown above and earlier? Ron
