This is a discussion on Re: move_fd() causing bad behavior on AIX5.3 - NTP ; Harlan Stenn wrote: > Danny wrote: >> Harlan Stenn wrote: >>> There is a good reason for the move_fd code. Frank would probably know >>> better, and he's on vacation for another 2-3 weeks' time. > >> Actually I was ...
Harlan Stenn wrote:
> Danny wrote:
>> Harlan Stenn wrote:
>>> There is a good reason for the move_fd code. Frank would probably know
>>> better, and he's on vacation for another 2-3 weeks' time.
>> Actually I was the one that wrote it and yes there are good reasons for
>> doing it.
> Cool - thanks for letting me know those things.
> Would you please *add* the good reasons to a comment in the code just
> before the definition of move_fd() when you get a chance? There are
> *plenty* of undocumented cases where we do something for a good reason
> nobody can remember anymore.
See Bug #614 and Friends. Yes, I guess it would help if we documented
everything especially bug #'s. And yes I have already forgotten the
>> However, if for some reason this causes a problem on his
>> particular O/S we can create a conditional macro to have it not use it.
> And until somebody besides you knows the good reason for move_fd(),
> nobody else will know if disabling move_fd() for AIX will be a good
> thing or if it will trade one problem for another (in this case, the
> underlying reason for having move_fd()).
If you actually create a macro around it it will be fine. It is only
currently used if F_DUPFD is defined. Reading the comments it is
documented why we do it. As I remember, I did the initial goaround and
then Frank picked it up. I suggest reading Bug #614 for details. The
code itself is not the best place for a detailed explanation.
>>> I think it has to do with making sure there is room to open different sorts
>>> of files, and may only be important if one has refclocks.
>>> But it could be Bad to disable move_fd() in general for AIX.
>> We don't know the general case to be able to answer that one.
> OK, so again, when the underlying reasons fo having move_fd() are
> documented (and therefore better known) in general, we have a chance of
> coming up with a better answer for this, too.
The code shows that that was already done.
>>> As for IPv6, are there any versions of AIX where IPv6 is working?
>> Yes, IPv6 does work on AIX. It's just that it's being confused by 6over4
>> and 4in6 and at least some versions of the O/S is not keeping the
>> address space separate. It should be running as a dual-stack or at least
>> not trying to play tricks with the address space.
> OK, sounds to me like that is an instance of "not working", at least as
> far as we are concerned.
IPv6 seems to be implemented in a strange way on AIX and it's hard to
say more without the source code.
> If there are known problems/issues with things like this, I would
> strongly request that people add this sort of information somewhere. It
> could be the code, or it could be at http://support.ntp.org/Dev .
> If we can figure out which versions of the OS do what, and if we can
> determine what OS version we have at runtime, we can have a single AIX
> executable DTRT depending on the OS verison (or patch level).
You might get some information from Mark about this, though he's at the
IETF meeting in Vancouver right now. He seems to know all the vagaries
of the different operating systems and versions having had to work
around most of these issues.