Hi!

Andy Bierman writes:

Andy> Hi, Andy> I haven't looked at the code yet, but...

Andy> I wanted to check with the smidump authors about the Andy> feasibility of modifying the smidump source code to Andy> act as an SMIv2 pretty print tool. I realize the Andy> complexity of such a tool depends on how configurable Andy> it is. I don't need any user configuration.

Smidump is based on the libsmi library. The library parses a given MIB module completely and stores the data in internal linked data structures, where the logical SMI details are kept, but not comments or "layout information" (the line# of definitions is the only exception). This is comparable to DOM in contrast to SAX.

So...

Andy> I noticed that smidump -f smiv2 will do some pretty printing, Andy> such as changing {foo 2} to { foo 2 }. I need this tool Andy> to format MIBs as they usually appear in RFCs:

Andy> - preserve ASN.1 comments

Not doable with the current library. Would require significant modifications. Corrently, comments are already dropped by the scanner, not the parser.

Andy> - one enum per line in INTEGER objects or TCs

Easy to change. Currently lines are filled with enum definitions up to a column where lines are wrapped. This seemed to look nicer, since we don't have any comments to print besides each enum definition.

Andy> - one descriptor and type per line in SEQUENCEs

It's already done this way with the types aligned according to the longest descriptor.

Andy> - one descriptor per line in OBJECTS and OBJECT-GROUP clauses

Same as for enums. As well for INDEX, NOTIFICATIONS, MANDATORY-GROUPS and maybe other constructs that I currently don't have in mind.

Andy> - uniform indentation and whitespace

I think it's already done in a quite common fashion. If changes would be needed, it should be easy.

Andy> - smart reformat to deal with lines > 72 chars

Smidump does not touch texts like in DESCRIPTIONs. This and maybe very long descriptors could lead to lines longer than 72 characters, e.g. in the above mentioned lines of a SEQUENCE construct where the longest descriptor and the longest used TC violate the 32-char-rule. Was this "SHOULD NOT rule" established for this reason? :-)

Andy> - many more details such as these?

The hardest problems that come to my mind spontaneously are the comments and the presumable requirement to keep the order of definitions as they are read from the input MIB module. The latter could be doable since the line numbers of definitions are available.

Andy> I would be willing to work on the code, but I wanted to check Andy> first with this group if this is possible or if anyone else Andy> has thought about such a tool.

I think this wish came up at least once in the past. But I cannot remember anyone willing to work on it actively.

-frank