On Tue, 21 Apr 2009, [email protected] wrote:
I think Erik's point was that we should separate this enable/disable address knob for the kernel from the administrative enable/disable knob. For example, the kernel version could be like an IFA_RUNNING flag, whereas the administrative one could be an IFA_UP flag.
Not sure this is a useful comment, more to help frame things.. apologies in advance if not.
In a way, you've got a hierarchy of 'enabledness' for any given address. You have various very specific "enabledness" booleans, like "administrative", "link", "DAD", etc.. which may be of interest to /some/ applications.
However, most applications really only care about the conjunction of them. So you probably want to provide such a flag. Otherwise it's a forward-compatibility nightmare as/when new kinds of specific notions of "enabledness" are added. IFA_UP/IFF_UP is probably the closest match for this one really, regardless of whether or not it was originally meant to be the "administrative" flag, no?
For addresses, setting a logical interface down causes the address to be withdrawn on PF_ROUTE - even while it remains visible via the ioctls() (with whatever additional flags). That's a pretty reasonable interface as far as most applications are concerned - iff it reflects the conjoined "UP" state (course, you can't bootstrap application state with PF_ROUTE, which is annoying).
regards, -- Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A Fortune: Waking a person unnecessarily should not be considered a capital crime. For a first offense, that is. _______________________________________________ networking-discuss mailing list [email protected]
