[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