Bug 1520

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