anchor.diff:  
   
   
  -==Sample Applications Details
  +== Sample Applications Details
   The general flow of Twister API applications is as follows:
   
   There are three sample applications developed for Twister API release 0.1. They include the following:
  
positive.code: 
  
  
  ===UDP Echo Server
  The UDP Echo server step by step explanation is below: 
   tw_init_global() Initialize the global environment for twister application by configuring ports and engines available on machine.
  
   tw_map_port_to_engine(): binds the a NIC port to a specific engine. So all the incoming/outgoing traffic on that port (tw<x>) will be managed by the engine (engine<x>). The description of port and engines is describe below.
  o A port-name (that could be tw0, tw1, depending upon the number of available ports on the machine)
  o An engine-name (engine0, engine1, depends on the number of available engines on the machine)
  
   In user_app_main(), the main logic of UDP ECHO application resides. Since this application only echoes back the incoming packets, we have to create a callback function which fires every time a packet arrives.
   tw_rx_t * server; is a pointer to callback struct that configures the rx_callback.   struct tw_rx_s { 
   	    uint8_t handle_type; 
                 uint64_t last_run_time; 
      int sock_fd; 
      struct tw_sockaddr_in * addr; 
      uint8_t flags; 
      void * recv_cb; 
      struct tw_rx_s * next; 
  };
  o handle_type tells which callback does that corresponds. Since it is a receive callback function. So we set its value to RX_CALLBACK. Currently we support only three types of callback functions, RX_CALLBACK, TX_CALLBACK, TIMER_CALLBACK.
  o last_run_time tells when was the last time this event was fired. Each time a packet arrives, timestamp to this variables would be updated. For the first-time we set it to 0.
  o recv_cb is a pointer to functions that will be executed each time receive event will occur. Our callback function is replay_payload so we set this pointer to function reply_payload. Every-time we receive a packet, the reply_payload function is called. In this function, the user can implement any RX logic. In our case, we echo the timestamp in the payload and send the UDP packet back to client.
   tw_default_loop(INFINITE_LOOP); creates an infinite eventloop handler and its address is returned as pointer. tw_default_loop() takes argument in seconds and run the event loop for that time. A value of 0 will make it run infinitely. The INFINITE_LOOP parameter has a value 0. This event-loop handler is described below:
  struct tw_loop_s { 
      void* data; 
                 uint8_t active_handles*-; 
      struct tw_rx_s * rx_handle_queue; 
      struct tw_tx_s * tx_handle_queue; 
      struct tw_timer_s * timer_handle_queue;
      unsigned int stop_flag;
      uint16_t secs_to_run; 
  };
  o data: user_data this could be used for any data/functions user want to use for this event-loop. 
  o active_handles: number of active handles currently this event-loop is managing. This could be multiple Rx, Tx, and timer handles. Twister main event-loop uses this. User dont need to deal with it.
  o rx_handle_queue: a link-list for all the Rx handlers.
  o tx_handle_queue: a link-list for all the Rx handlers.
  o imer_handle_queue: a link-list for all the timer handlers.
  o stop_flag:  flag is raised when event-loop timer expires.
  o secs_to_run: number of seconds for which this event-loop would be run.
   tw_rx_init(tw_loop); would add an Rx handler to event-loop(tw_loop) and return the pointer to new handler added to rx_handle_queue of event-loop.tw_run(tw_loop);
   tw_rx_start(server, reply_payload); would assign the receive call back function to receive handler. So everytime receive event occurs i.e., a packet is received, the call back function assigned to the handler would be executed. It takes two arguments:
  o server:  a pointer to receive handler of type tw_rx_s.
  o reply_payload:  A receive callback function.
   tw_run(tw_loop); takes a configured event-loop handler and execute it for whatever time the user has configured it.
  
  
  
  
negative.code: 
  
  
  == Initialization Module
  The initialization module of API handles the initialization of twister abstraction layer. Abstraction layer consists of the following parts:
  * System Memory Reservation: The abstraction layer facilitates the reservation of different memory zones, for example, physical memory areas for device interactions.
  * Allocate PCI resources and set up the physical device and the link
  