[Xorp-hackers] Xorp for embedded applications

[Pavlin Radoslavov]

Ben Greear <greearb at candelatech.com> wrote:

> Sonia wrote:
> > Hi all, 
> > 
> > Recently I wrote to this list asking for help to
> > reduce the size of xorp binaries in order to make them
> > fit in an embedded platform. 
> > 
> > http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2007-September/001180.html
> > 
> > First of all, thank you Pavlin for your quick answer!
> > 
> > As said in the previous post, we only need some
> > functionalities of xorp. Specifically we want to
> > implement the feature of multicast router, so as
> > Pavlin said, we need only some of the binaries of xorp
> > (xorp_igmp, xorp_finder, xorp_fea and the template
> > files). 

This is off-topic, but I should clarify it here:

If I remember correctly, in your original email you said you need
IGMP. If you need "multicast router", then you need to add
xorp_pimsm4 as well. Binary xorp_igmp implements the router-side of
IGMP, but this itself is not useful.

> > We don't mind to have few binaries in our system, but
> > the size of them is prohibitive (We have 4MB of
> > Flash). For example, we've tried disabling IPv6, but
> > adding the compilation flag doesn't remove all the
> > functions related to IPv6 and the size is not reduced.
> > 
> > We think also that it could be very interesting to use
> > shared libraries, or to have the choice to make a
> > single binary with the selected features. Obviously we
> > focus on embedded world.
> > 
> > I don't know if there is some work on this. Although
> > we would like to contribute to it, unfortunatly we
> > don't have time.
> > 
> > To sum up, we ask for ideas to reduce the size of the
> > binaries or if anyone is interested in doing this work
> > we're considering to make a donation. 
> 
> Once you strip the executables and use shared libraries,
> I think if you want to make it smaller, you'll need
> to start modifying code.  Xorp uses lots of templates
> and these tend to bloat executable size.  You
> might be able to replace some of the template code
> with regular classes.
> 
> There is also a lot of mostly trivial classes..like for
> each of the xlr commands (I think that terminology is right).
> 
> These classes could be re-written to become methods of a larger class.
> 
> You could remove much of the inline implementations in header files
> and move that to .cc files.  This is generally trivial work that does
> not require a real understanding of the code.
> 
> The stl, especially the string class, does much of it's work inline
> as well.  If you replace the string class with something simpler
> that does not inline everything, you will likely save a lot of space.
> 
> Thanks,
> Ben


I should mention first that originally when we started XORP we
weren't looking into the embedded device space. Hence, so far the
optimization of the binary executable size and the process runtime
size haven't been priority.

You could try experimenting with Ben's suggestions above, and myself
I would be interested to know how much each of them makes
difference.

In addition, you could try various C/C++ compiler flags to see
whether any of them will help. For example, there are some gcc flags
related to inlined code.

-fno-implicit-inline-templates
-fno-implement-inlines
-fno-default-inline
-fno-inline

Check the gcc/g++ manual page whether any of them are applicable.
It might be worth reading the whole manual page to see if there are
any other candidates.

Before doing so you might want to try first the latest code from CVS
and to see whether the (refactored) FEA is smaller than the FEA from
XORP-1.4. There might not be any notable difference (or the size
could be worse), but is worth trying it.

Nevertheless, we are (slowly) changing things in the direction of
reducing the binary size.
For example, we intend to start using shared libraries (at least for
the FEA), but we haven't done that yet.
In any case we need to perform more systematic audition of the code
to address the memory size issues.

Good luck!
Pavlin