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, run the simulations without the full path ingredient

  • Note the new fingerprints; they are correct because the model didn’t change

  • Perform renaming

  • Run the simulations again with the new fingerprints; the new fingerprints are not sensitive to changes in submodule names

Note

To run fingerprints with tlx, delete the p from the ingredients. Use the inet command in the tutorial directory. The command does not change the store.

Here is the workflow demonstrated using a simplistic example:

We run the simulations with the tlx ingredients. The fingerprint 0000-0000/tlx is a dummy value. It makes the run fail, and the run prints the calculated value:

$ inet -u Cmdenv -c Ethernet -r 0 --sim-time-limit=0.2s --fingerprint=0000-0000/tlx
$ inet -u Cmdenv -c Wifi -r 0 --sim-time-limit=5s --fingerprint=0000-0000/tlx

Fingerprint mismatch! calculated: XXXX-XXXX/tlx, expected: 0000-0000/tlx
Fingerprint mismatch! calculated: XXXX-XXXX/tlx, expected: 0000-0000/tlx

As expected, they fail because the dummy value is wrong. Note the two calculated values. There was no change in the model, so they are correct.

When we run the simulations again with the calculated values, they pass:

$ inet -u Cmdenv -c Ethernet -r 0 --sim-time-limit=0.2s --fingerprint=XXXX-XXXX/tlx
$ inet -u Cmdenv -c Wifi -r 0 --sim-time-limit=5s --fingerprint=XXXX-XXXX/tlx

Fingerprint successfully verified
Fingerprint successfully verified

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:

--- /home/runner/work/inet/inet/tutorials/fingerprint/sources/LinkLayerNodeBase.ned.orig
+++ /home/runner/work/inet/inet/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 {

--- /home/runner/work/inet/inet/tutorials/fingerprint/sources/NetworkLayerNodeBase.ned.orig
+++ /home/runner/work/inet/inet/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 simulations again with the same fingerprints:

$ inet -u Cmdenv -c Ethernet -r 0 --sim-time-limit=0.2s --fingerprint=XXXX-XXXX/tlx
$ inet -u Cmdenv -c Wifi -r 0 --sim-time-limit=5s --fingerprint=XXXX-XXXX/tlx

Fingerprint successfully verified
Fingerprint successfully verified

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

Now, we can run the update command with the tplx ingredients to record the new values in the store (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:

--- /home/runner/work/inet/inet/tutorials/fingerprint/sources/Ipv4NetworkLayer.ned.orig
+++ /home/runner/work/inet/inet/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");
         }

We run the simulation with the tlx fingerprint:

$ inet -u Cmdenv -c Wifi -r 0 --sim-time-limit=5s --fingerprint=XXXX-XXXX/tlx

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

The simulation gives 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