Hi Ralph, thanks for your reply. > > Right. And there is some additional special-casing, including (again, > assuming I'm recalling the details correctly) using 0 to represent 16. It's > an interesting observation that the various decompression mechanisms share > the construct of copying a prefix from somewhere, (optional) zero-fill and > copying an IID from somewhere. However, I found the resulting code somewhat > opaque. > Another point is the case is SAM = 10b or DAM = 10b and M = 0. This case need a uncrompression to a address: fe:80::ff:fe00:XXXX
and the current function don't set the ff:fe bits. It need a special handle in this function, but then we can't use the function for a multicast uncompression because a multicast address don't set these bits. We need something like (!lladdr && address_mode == 2) which !lladdr identifier that is currently a non-multicast uncompression. This looks very awful :( grml... It's very hard to hold this current idea with the pre and post array information.... Alex ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
