Hello Hugo, Hugo Santos wrote: > Hi, > >> On the other hand, if a ND daemon loose the synchronization, it is >> unpredicable, I guess. > > What do you mean by synchronization in this context? My idea was to > keep the ND state machine inside the kernel, and instead have the > daemon be reactive. That means it would send messages on behalf of the > kernel, and apply information based on received signalling (besides, ND > is reseliant to loss of messages). Taking your example, if the kernel > is using a neighbor entry and you replace it (either changing it's > state or link-layer address), the kernel will adapt, i believe it is > predictable. To be honest, i'm only worried about possible lost netlink > messages; but the daemon may be implemented to handle this, re-sending > while an ACK isn't receiving, thus minimizing any de-synchronization > possibilities. >
The kernel maintains the ND state by itself and the daemon touches the state. I think the daemon should aware the state. It is what I meant with "synchronization". Anyway I do not intend to prevent you from your work anymore. I quit discussion without seeing the codes. >> BTW, we have a choice which we implement a functionality as a >> module. I think it can achieve some of what you want. > > Well, exporting the functionality to a module would be a start to > have one moving it out of the kernel. :-) > > Hugo -- Kazunori Miyazawa - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
