Bugzilla – Bug 1520
config paths not documented in Doxygen for CsmaChannel (possibly others)
Last modified: 2013-01-18 16:09:25 EST
The config path for attributes and trace sources is typically documented in the GetTypeId() of a class, e.g. http://www.nsnam.org/docs/doxygen/classns3_1_1_csma_net_device.html#aee49acd8c695a21662f2111c7771e92b For CsmaChannel (possibly others), this path is missing: http://www.nsnam.org/docs/doxygen/classns3_1_1_csma_channel.html#a58ca8d59505018b8a4bfe9288bbd2066 For objects associated with a Node, these are typically accessed through the NodeList which is registered in the Config namespace at the root: Ptr<NodeListPriv> * NodeListPriv::DoGet (void) { static Ptr<NodeListPriv> ptr = 0; if (ptr == 0) { ptr = CreateObject<NodeListPriv> (); Config::RegisterRootNamespaceObject (ptr); Simulator::ScheduleDestroy (&NodeListPriv::Delete); } return &ptr; } Similar code is in channel-list.cc, yet we don't see paths documented such as /ChannelList/...
Can you give an example of a config path that is missing for the CsmaChannel? Both of the links to doxygen for the two classes have no config paths in their GetTypeId specification.
(In reply to comment #1) > Can you give an example of a config path that is missing for the CsmaChannel? > > Both of the links to doxygen for the two classes have no config paths in > their GetTypeId specification. That is the point. They have attributes unreachable through the config filesystem paths that are documented. lines 39-47 of: http://code.nsnam.org/ns-3-dev/file/9c62cfdc7946/src/csma/model/csma-channel.cc The doxygen says: "This type is not accessible from the Config system." http://www.nsnam.org/docs/doxygen/classns3_1_1_csma_channel.html#aa9cf8af00b00403b00c004c6d8ea468c
Is the problem the text in the message? "This type is not accessible from the Config system." If the problem is that there are missing paths for these attributes that are not shown, which paths are they? There has to be an instance in the ns-3 code base where the attributes are actually used by another object before they show up in the config paths for ns-3. Is there an instance where the csma-channel is used by another ns-3 object that is not showing up the doxygen?
(In reply to comment #3) > Is the problem the text in the message? > > "This type is not accessible from the Config system." > > If the problem is that there are missing paths for these attributes that are > not shown, which paths are they? > > There has to be an instance in the ns-3 code base where the attributes are > actually used by another object before they show up in the config paths for > ns-3. > > Is there an instance where the csma-channel is used by another ns-3 object > that is not showing up the doxygen? There has to be an instance of an object in the main() of print-introspected-doxygen for the path to get registered in the config database. Presently, there is this: NodeContainer c; c.Create (1); StaticInformation info; info.RecordAggregationInfo ("ns3::Node", "ns3::TcpSocketFactory"); info.RecordAggregationInfo ("ns3::Node", "ns3::UdpSocketFactory"); info.RecordAggregationInfo ("ns3::Node", "ns3::PacketSocketFactory"); info.RecordAggregationInfo ("ns3::Node", "ns3::olsr::RoutingProtocol"); info.RecordAggregationInfo ("ns3::Node", "ns3::MobilityModel"); info.RecordAggregationInfo ("ns3::Node", "ns3::Ipv4L3Protocol"); info.RecordAggregationInfo ("ns3::Node", "ns3::ArpL3Protocol"); There are a few things that need to be done here. 1) (hypothesis) we need to create instances of all channel objects, and verify that this causes their path to show up in the Doxygen. These are probably the important ones that have attributes: PointToPointChannel PointToPointRemoteChannel WimaxChannel YansWifiChannel SingleModelSpectrumChannel MultiModelSpectrumChannel UanChannel BridgeChannel This will require the relevant headers to be included in the print-introspected-doxygen.cc file, and also the wscript module dependencies need to be extended accordingly (depends only on 'network' presently). obj = bld.create_ns3_program('print-introspected-doxygen', ['network']) These new objects may also need to be lightly touched in some way to avoid "object unused" warnings. 2) The aggregation info needs to be extended. For instance, we have this: info.RecordAggregationInfo ("ns3::Node", "ns3::Ipv4L3Protocol"); but Ipv6L3Protocol is lacking, and hence it doesn't show up in the Doxygen. We need to add similar statements to update the Node aggregation list for the current Internet protocols. I don't have this list handy at the moment but should include, at least, Ipv6l3Protocol and Icmpv6L4Protocol. 3) After this low hanging fruit is taken care of, probably need to audit the documentation output for instances of "This type is not accessible from the Config system", and if it is believed that this type should be accessible, instantiate the required object or add the necessary RecordAggregationInfo() to make it show up.
Step 1) is solved by the following changeset: 1d2a0119e60c Step 2) requires a complete list of classes that are missing from the set of classes that are recorded as being aggragated to nodes Step 3) requires someone to audit the list of types that are not accessible.
Step 2) is solved with this changeset bb6bbda68e97 which added the following classes ArpL3Protocol Ipv4L3Protocol Icmpv4L4Protocol UdpL4Protocol Ipv6L3Protocol Icmpv6L4Protocol TcpL4Protocol NscTcpL4Protocol This still needs to be done: 3) After this low hanging fruit is taken care of, probably need to audit the documentation output for instances of "This type is not accessible from the Config system", and if it is believed that this type should be accessible, instantiate the required object or add the necessary RecordAggregationInfo() to make it show up.
Bug closed. ns-3-dev changeset: b72fd6e6a4b5