Rémi, On Monday 12 March 2007 18:07, Rémi Denis-Courmont wrote: > Le lundi 12 mars 2007 18:50, Julien Laganier a > écrit : > > Now what your example essentially does is: > > > > - compile an old library on an old system without > > the new API so that is conforms to the old ABI. > > > > - compile a piece of code on a new system with the > > new API so that it conforms to the new ABI. > > > > - link the piece of code conforming with the new > > ABI with a library conforming to an old ABI. > > > > Surprise: it breaks! > > Of course it breaks.
That was irony, FWIW. > I am well aware that there some > systems have versioning capabilities and all to > handle this... But, err, we are dealing with the > system C library here! Breaking that means you have > to rebuild and update the whole system (well, the C > library, and every thing that depends on it, so > almost the whole system). Very hard in general, and > outright IMPOSSIBLE if you happen to support a > platform with third party closed-source software. My point has been that we do not break backward ABI compatibility Rebuilding the whole OS is what you do when you update the C library. Now if you're using closed source libraries for the old version of the OS, you can still use software compiled on the old OS and linked against that old library. It's not the problem of the OS or its ABI compatibility if you insist on linking software compiled on the new OS with outdated libraries supporting the old OS. It's the probelm of your third party software vendor: You should just ask straight to him for new versions of these libraries compiled on the new system. > Continuing this way, you can be sure that some OS > vendors will either not implement this, or do it in > a non-standard way. With these considerations, it is > much more practical to define a new API name. > > Besides, since in anycase, addrselect-aware > applications and libraries will need source code > modification, what is the problem with the latter > approach? We cannot invent new API names and functions each time someone insists on using an old library on a new system and link it with new software. > > Regarding the need for an application to save > > defaults if it want to restore them, I don't see > > that saving requirement as an issue. As we saw > > before, an application has already many things to > > save (e.g. save a value of the pointer to an > > addrinfo structure if it wants to free it :) > > 1/ That's completely different. The addrinfo > structure lifetime is much shorter than that of a > network socket, both in term of source code path, > and real time clock. > 2/ That's not at all an excuse for *both* deviating > from existing established practices AND making the > API harder to use. That makes TWO (however minor > that may be) inconveniences, with ZERO benefits. First of all, note that I don't care much about this. It has been in the draft since the beginning, and besides you nobody ever complained about it. Regarding the point you made in your previous note: > [...] simplify implementors life a lot (there are so > many case where you just pass socket handles through > different layers, and simply cannot pass anything > else without large changes). So here you mean that you cannot pass that saved system default without rewriting the software, right? But presumably, if the code want to reset system default on a given socket, it has to know they've been altered, right? So still you need to pass that something else that says "address selection preferences altered" Or do you assume such code will blindly reset socket preference each time a socket handles passes through layer boundaries? So IMHO your point doesn't raise an issue with the current design. > These issues were already raised more than 6 months > ago. Are you trying to optimize for one specific > vendor that would have already shipped a draft > implementation ?? Rémi, please abstain to suggest such things, this is not helping the discussion we're having here. > I have been asking for a rationale for as long, and > still haven't received any sane answer. I hope you do not find my answers insane... > I really don't understand why you stick that > hard to a broken design. Please see above. What is IMHO broken is 1) linking code compiled on a new system with libraries compiled an old system, dynamic linking isn't like composing a bouquet, and 2) blindingly resetting socket address selection preference because someone doesn't want to rewrite code. --julien -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
