[Xorp-hackers] static xrl interface calls

[Li Zhao]

The last piece of puzzle was solved. The task which was added to the task manager was a TaskXrlItem. When this task was fired, the execute method in TaskXrlItem was asking _xorp_client to send a unresolved xrl request.

The reason why XrlStaticRoutesV0p1Client methods were not called, I guess, was because rtrmgr needs to utilize its task and taskmanager mechanism. If there is another process which does not have moduel, task, or taskmanager, then XrlStaticRoutesV0p1Client methods can be used directly and will have the similar code flow eventually.

Li


--- On Mon, 10/12/09, Li Zhao <lizhaous2000 at yahoo.com> wrote:

> From: Li Zhao <lizhaous2000 at yahoo.com>
> Subject: Re: [Xorp-hackers] static xrl interface calls
> To: "Ben Greear" <greearb at candelatech.com>
> Cc: xorp-hackers at icir.org
> Date: Monday, October 12, 2009, 12:50 PM
> You are right. We are finding the
> same thing.
> What I found is the configure tree node is traversed.
> Please watch etc/template/static_routes.tp:
> 
> route @: ipv4net {
>       %create xrl
> "$(static.targetname)/static_routes/0.1/add_route4?..."
> 
> What happened was when the leaf node was processed, the
> corresponding command will call Command::execute which in
> turn will call XrlAction::execute. It was adding an xrl to
> the task manager so the task manager will have a penfing
> action. That is why I can not see explicate call to
> XrlStaticRouteV0p1Client methods.
> 
> I am studing now how the task manager is mapping from
> xrl->_action->_request to the real xrl calls.
> 
> I am getting much closer now.
> 
> Thanks.
> 
> Li
> 
> 
> --- On Mon, 10/12/09, Ben Greear <greearb at candelatech.com>
> wrote:
> 
> > From: Ben Greear <greearb at candelatech.com>
> > Subject: Re: [Xorp-hackers] static xrl interface
> calls
> > To: "Li Zhao" <lizhaous2000 at yahoo.com>
> > Cc: xorp-hackers at icir.org
> > Date: Monday, October 12, 2009, 11:44 AM
> > Li Zhao wrote:
> > > I have used gdb and cscope to trace the code flow
> as
> > following:
> > > commit_changes -> send_apply_config_change
> -> |
> > rtrmgr_0_1_apply_config_change
> ->apply_config_change
> > -> change_config -> commit_change_pass1 ->
> > commit_change_pass2 -> commit_changes.
> > > 
> > > But i still can not find the code in rtrmgr
> explicitly
> > calling (ANY) xrl interface functions to any target
> module.
> > > On the other hand the target mudule did receive
> STCP
> > ios and the corresponding target functions were
> called.
> > > 
> > > I do not think in the case of adding static
> route
> > rtrmgr can talk to fea directly. The only puzzle was
> how on
> > the earth rtrmgr called the function
> > xrlStaticRouteV0p1Client::send_add_route4.
> > > 
> > > Thanks for you reply.
> > >   
> > 
> > Damn...what complicated code.  Just spent an hours
> > trying to follow the commit
> > logic.
> > 
> > Anyway, I think it comes down to TaskXrlItem
> > 
> > An entry point to this code might be:
> > 
> > template_commands.cc:
> > int
> > XrlAction::execute(const MasterConfigTreeNode&
> ctn,
> >           TaskManager&
> > task_manager,
> >           XrlRouter::XrlCallback
> > cb) const
> > 
> > called from:
> > module_command.cc:
> > void
> > ModuleCommand::add_action(const
> list<string>&
> > action, const XRLdb& xrldb)
> >    throw (ParseError)
> > {
> > 
> > I cannot figure exactly how this ties back in, but I
> think
> > all of this must be called from:
> > 
> > master_conf_tree_node.cc:
> > bool
> > MasterConfigTreeNode::commit_changes(TaskManager&
> > task_manager,
> >                
> >     bool do_commit,
> >                
> >     int depth, int last_depth,
> >                
> >     string& error_msg,
> >                
> >     bool& needs_activate,
> >                
> >     bool& needs_update)
> > {
> > 
> > 
> > Commands are added directly by some parser, probably
> of the
> > .xif files or something like that.
> > 
> > Probably would take enabling logging and then reading
> the
> > logs very carefully to figure out
> > exactly how it actually works.
> > 
> > Thanks,
> > Ben
> > 
> > -- Ben Greear <greearb at candelatech.com>
> > Candela Technologies Inc  http://www.candelatech.com
> > 
> > 
> > 
> 
> 
> 
>