[Xorp-hackers] HEADS UP: Tree breakage.

Bruce Simpson bms at incunabulum.net
Thu Dec 3 13:14:26 PST 2009


Bruce Simpson wrote:
> Hi all,
>
> I am currently updating the tree to use FHS-style paths.
>
> This is going to involve some tree breakage, for within the next day or so.
> I should have it ironed out tomorrow.
>   

I'd say this work is about 60% complete.

I need to update the Router Manager to recognise the FHS style paths.

As of r11648, XORP binaries are installed as follows:
$prefix/sbin                    xorpsh, router manager and profiler
$prefix/lib/xorp/bin            anything in */tools/*
$prefix/lib/xorp/sbin           all protocol modules
$prefix/lib/xorp/lib            all shared libraries
$prefix/share/xorp/templates    templates (are arch independent data)
$prefix/share/xorp/xrls         *.xrls if and only if debug_xrldb=true


Only the Router Manager needs to see the template files.

The *.xrls files are only needed if debugging the *.xrls invocation.
In Thrift, these go away, as it is no longer necessary to validate the 
XRL calls on a method-by-method basis.

The decision to place all the shared libraries in lib/xorp/lib was taken 
for these reasons:
 1. No external programs use them directly, therefore they don't belong 
in $prefix/lib.
 2. Spamming $prefix/lib can cause lookup slowdown, particularly with 
embedded filesystems.
 3. It makes it easier to use $ORIGIN relative paths in the ELF runtime 
linker, for the components
     installed in $prefix/lib/bin and $prefix/lib/sbin.

The xorp_finder and call_xrl binaries are no longer installed; nothing 
in a production deployment needs them, and they are highly specific to 
XORP's IPC. I'd envisage that they can be replaced, in the Thrift world, 
with Python scripts.

These changes should make it a bit easier to add new components to the 
system at runtime, as well as making it easier on people packaging XORP 
for deployment in Linux distributions.

thanks,
BMS



More information about the Xorp-hackers mailing list