Table Of Contents
Table Of Contents

Renaming a Submodule

Renaming submodules can cause the fingerprints to change, because the default ingredients (tplx) contain the full module path, thus the submodule name as well. Renaming submodules can cause regression in some cases, e.g. when functionality depends on submodule names (e.g. submodules referring to each other).

To go around the problem of fingerprints failing due to renaming, the fingerprints need to be calculated without the full path:

  • Before making the change, rerun fingerprint tests without the full path ingredient

  • Update fingerprints; the new values can be accepted because the model didn’t change

  • Perform renaming

  • Run fingerprint tests again; the new fingerprints are not sensitive to changes in submodule names

Note

To run fingerprints with tlx, delete the p from the ingredient in the .csv file. When the fingerprint test is run again, the fingerprints will be calculated with the new ingredients. The tests will fail, as the values are still the ones calculated with tplx, but it is safe to overwrite them with the updated values, as the model didn’t change.

Here is the workflow demonstrated using a simplistic example:

We set the fingerprint ingredients to tlx in the .csv file:

.,        -f omnetpp.ini -c Ethernet -r 0,           5s,         a92f-8bfe/tlx, PASS,
.,        -f omnetpp.ini -c Wifi -r 0,               5s,         5e6e-3064/tlx, PASS,

Then we run the fingerprint tests:

$ inet_fingerprinttest -m RenamingSubmodule
. -f omnetpp.ini -c Ethernet -r 0  ... : FAILED (should be PASS)
. -f omnetpp.ini -c Wifi -r 0  ... : FAILED (should be PASS)

As expected, they fail because the values are still the ones calculated with tplx. We can update the .csv file with the new values:

$ mv baseline.csv.UPDATED baseline.csv

When we rerun the fingerprint tests, now they PASS:

$ inet_fingerprinttest -m RenamingSubmodule
. -f omnetpp.ini -c Ethernet -r 0  ... : PASS
. -f omnetpp.ini -c Wifi -r 0  ... : PASS

As a simplisic example, we rename the eth module vector to ethernet in LinkLayerNodeBase and NetworkLayerNodeBase. This change affects all host-types such as StandardHost and AdhocHost since they are derived modules:

--- /docs/doc/src/tutorials/fingerprint/sources/LinkLayerNodeBase.ned.orig
+++ /docs/doc/src/tutorials/fingerprint/sources/LinkLayerNodeBase.ned.modified
@@ -59,7 +59,7 @@
             parameters:
                 @display("p=300,526,row,150;q=txQueue");
         }
-        eth[sizeof(ethg)]: <default("EthernetInterface")> like IEthernetInterface {
+        ethernet[sizeof(ethg)]: <default("EthernetInterface")> like IEthernetInterface {
             parameters:
                 @display("p=900,526,row,150;q=txQueue");
         }
@@ -78,7 +78,7 @@
         }
 
         for i=0..sizeof(ethg)-1 {
-            ethg[i] <--> { @display("m=s"); } <--> eth[i].phys;
+            ethg[i] <--> { @display("m=s"); } <--> ethernet[i].phys;
         }
 
         for i=0..sizeof(pppg)-1 {

--- /docs/doc/src/tutorials/fingerprint/sources/NetworkLayerNodeBase.ned.orig
+++ /docs/doc/src/tutorials/fingerprint/sources/NetworkLayerNodeBase.ned.modified
@@ -61,8 +61,8 @@
         }
 
         for i=0..sizeof(ethg)-1 {
-            eth[i].upperLayerOut --> nl.in++;
-            eth[i].upperLayerIn <-- nl.out++;
+            ethernet[i].upperLayerOut --> nl.in++;
+            ethernet[i].upperLayerIn <-- nl.out++;
         }
 
         for i=0..sizeof(pppg)-1 {

We run the fingerprint tests again:

$ inet_fingerprinttest -m RenamingSubmodule
. -f omnetpp.ini -c Ethernet -r 0  ... : PASS
. -f omnetpp.ini -c Wifi -r 0  ... : PASS

As expected, the fingerprints didn’t change, so we can assume the model is correct.

Now, we can change the ingredients back to tplx, rerun the tests, and accept the new values (described in more detail in the Accepting Fingerprint Changes step).

However/In other cases, renaming submodules can lead to ERROR in the fingerprint tests, e.g. when modules cross-reference each other and look for other modules by name. Also, renaming can lead to FAILED fingerprint tests, because there might be no check in the model on cross-referencing module names.

Note

Before trying the following example, reset the model changes of the previous example.

Here is an example change which results in ERROR in the tests when using tlx fingerprints:

In Ipv4NetworkLayer, we rename the routingTable submodule to ipv4RoutingTable:

--- /docs/doc/src/tutorials/fingerprint/sources/Ipv4NetworkLayer.ned.orig
+++ /docs/doc/src/tutorials/fingerprint/sources/Ipv4NetworkLayer.ned.routingtable.modified
@@ -43,7 +43,7 @@
             parameters:
                 @display("p=100,100;is=s");
         }
-        routingTable: Ipv4RoutingTable {
+        ipv4RoutingTable: Ipv4RoutingTable {
             parameters:
                 @display("p=100,200;is=s");
         }

Here are the results of the fingerprint tests:

$ inet_fingerprinttest -m RenamingSubmodule
. -f omnetpp.ini -c Wifi -r 0  ... : ERROR (should be PASS)
. -f omnetpp.ini -c Ethernet -r 0  ... : ERROR (should be PASS)

The simulations finished with an error, because the Ipv4NetworkConfigurator module was looking for the routing table module by the original name, and couldn’t find it.

Note that we omitted the error messages from the above output to make it more concise. The simulations give the following error message:

Error: Module not found on path 'RegressionTestingTutorialWireless.host1.ipv4.routingTable'
defined by par 'RegressionTestingTutorialWireless.host1.ipv4.configurator.routingTableModule'
-- in module (inet::Ipv4NodeConfigurator) RegressionTestingTutorialWireless.host1.ipv4.configurator
(id=83), during network initialization
Previous
Easy to Handle Changes
Next
Renaming a Module Parameter