Bugzilla – Bug 2816
Split MAC in abstract class and concrete class
Last modified: 2017-11-13 19:08:50 EST
Created attachment 2948 [details] changeset I'm taking over the old GSoC work of Vishwesh Rege (ContikiMAC for LrWpan). It needs still some work and validation, but this patch is simple enough to be applied. It splits the MAC into two entities: one abstract (LrWpanMac) and one concrete (LrWpanNullMac). The other patches will require some more work and are: 1) ContikiMac, and 2) Energy consumption for ContikiMac. There will be NO support for energy consumption in NullMAC, simply because NullMAC is not energy-friendly. All the tests are passing, of course.
Created attachment 2952 [details] correct changeset
Can you please update the .rst with the new design architecture, and the class documentation? This patch doesn't seem to make LrWpanMac abstract, only to introduce a new intermediate base class. Is the NullMac supposed to model the Contiki NullMac? If so, can you state this in the class documentation?
"NullMac" is the Contiki definition of the existing MAC. We can opt for a different name, of course, but I have a very short imagination. The LrWpanMac is abstract thanks to this function: virtual void SetLrWpanMacState (LrWpanMacState macState) = 0; actually, it's the only one that is required to be changed between NullMac (or whatever name we want to use) and ContikiMac (I'm reviewing it). Documentation... I'm on it. (In reply to Tom Henderson from comment #2) > Can you please update the .rst with the new design architecture, and the > class documentation? This patch doesn't seem to make LrWpanMac abstract, > only to introduce a new intermediate base class. Is the NullMac supposed to > model the Contiki NullMac? If so, can you state this in the class > documentation?
Created attachment 2954 [details] changeset + doc