jamal wrote: > On Fri, 2006-23-06 at 16:32 +0200, Patrick McHardy wrote: > >>I don't think it should carry both old and new speed. Netlink >>notifications usually provide a snapshot of the new state, but >>no indication what changed, with one notable exception, the >>ifi_change field, which IMO is a hack for lazy userspace. > > > I am quiet fond of the ifi_change ;-> > >>Since >>notifications can get lost, userspace needs to resync occasionally. >>The naiive approach (works for every other object) to determine if >>the object state changed from my last known state is to compare >>all attributes .. > > > scalability issues abound when you have a gazillion things to look at. > There used or may still be a way to tell from looking at netlink socket > that an error occurred since last time - such as "a message was lost". > You could use that to tell a message was lost and do scanning only > then.
It returns -ENOBUFS on socket overrun. Without it netlink notifications wouldn't be very useable as you couldn't figure out when you missed some. >> but the ifi_change field will be different >>between notifications and dumps even if the object itself didn't >>change. "Lazy userspace" because looking at ifi_change is obviously >>only useful if it doesn't keep its last known state and tries to >>derive the change from update notifications alone .. which means it >>fails when notifications are lost. >> > > > But thats not the real intent for it. Then what is the intent, it doesn't carry any other information? It includes information that are not available any other way from the kernel, yet the information is not transmitted reliably. How could a program that relies on this possibly work reliable? - 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
