[Cross-Compile] What's the difference of `./configure` option `--build`, `--host` and `--target`?

When using ./configure especially in cross-compiling purpose, I kind of confuse about the option --build and --host so that the following content is what I found on searching:

some remarks on specifying --host=<host>, --target=<target> and --build=<build
# kindly provided by Keith Marshall:
# 1) build
# this is *always* the platform on which you are running the build
# process; since we are building on Linux, this is unequivocally going to
# specify `linux', with the canonical form being `i686-pc-linux-gnu'.
#
# 2) host
# this is a tricky one: it specifies the platform on which whatever we
# are building is going to be run; for the cross-compiler itself, that's
# also `i686-pc-linux-gnu', but when we get to the stage of building the
# runtime support libraries to go with that cross-compiler, they must
# contain code which will run on the `i686-pc-mingw32' host, so the `host'
# specification should change to this, for the `runtime' and `w32api'
# stages of the build.
#
# 3) target
# this is probably the one which causes the most confusion; it is only
# relevant when building a cross-compiler, and it specifies where the code
# which is built by that cross-compiler itself will ultimately run; it
# should not need to be specified at all, for the `runtime' or `w32api',
# since these are already targetted to `i686-pc-mingw32' by a correct
# `host' specification.

And I found an answer after posting this question.. Still posting it here in case it helps someone else in the future.
http://jingfenghanmax.blogspot.in/2010/09/configure-with-host-target-and-build.html

As per this blog in my case
build will be i686-pc-linux-gnu ( My PC)
host will be mipsel-linux ( The platform I am going to run my code on)
target will be used if I am building a cross-compiling toolchain.
Since I am not building a toolchain, I didnt have to specify target.

 You will have to cross-compile libusb and then copy the library and
header files to a location where your toolchain can locate them. In
the case of CodeSourcery, you can put them in
cs_root/arm-none-linux-gnueabi/lib and
cs_root/arm-none-linux-gnueabi/include for example. You will also need
the library on the target's root filesystem unless you link it
statically, please mind the licencing implications if you do though.

[NETCONF] The summary of NETCONF Content

The following content is about the summary of the NET-CONF web site: 

http://www.netconfcentral.org/netconf_docs

Session Initiation For Clients

   <?xml version="1.0" encoding="UTF-8"?>
          <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
            <capabilities>
       <capability>urn:ietf:params:netconf:base:1.0</capability>
            </capabilities>
          </hello>]]>]]>

Protocol Capabilities

<capability>
    urn:ietf:params:netconf:capability:writable-running:1.0
</capability>

 <capability>urn:ietf:params:netconf:base:1.0</capability>

Standard Capabilities

:candidate

:confirmed-commit

:interleave

:notification

:partial-lock

:rollback-on-error

:startup

:url

:validate

:writable-running

:xpath

Configuration Databases

<running/>

<candidate/>

<startup/>

Protocol Operations

Once a NETCONF session is established, the client knows which capabilities the server supports. The client then can send RPC method requests and receive RPC replies from the server. The server's request queue is serialized, so requests will be processed in the order received.

Operation	Usage	Description
close-session	:base	Terminate this session
commit	:base AND :candidate	Commit the contents of the <candidate/> configuration database to the <running/> configuration database
copy-config	:base	Copy a configuration database
create-subscription	:notification	Create a NETCONF notification subscription
delete-config	:base	Delete a configuration database
discard-changes	:base AND :candidate	Clear all changes from the <candidate/> configuration database and make it match the <running/> configuration database
edit-config	:base	Modify a configuration database
get	:base	Retrieve data from the running configuration database and/or device statistics
get-config	:base	Retrieve data from the running configuration database
kill-session	:base	Terminate another session
lock	:base	Lock a configuration database so only my session can write
unlock	:base	Unlock a configuration database so any session can write
validate	:base AND :validate	Validate the entire contents of a configuration database

http://www.netconfcentral.org/slides/netconf/netconf_tutorial.html

NETCONF and Yang
https://www.ietf.org/proceedings/75/slides/opsarea-5.pdf
http://www.slideshare.net/cmoberg/a-30minute-introduction-to-netconf-and-yang
http://packetpushers.net/using-netconf-yang-to-configure-network-devices-and-why-it-does-not-replace-snmp/
http://packetpushers.net/using-netconf-yang-to-configure-network-devices-and-why-it-does-not-replace-snmp/

[OpenStack] The resource list for studying OpenStack Neutron

The following list is about the resource documents for those who want to study OpenStack Neutron. It may reduce the time you spend on searching. Here you go:

Introduction to OpenStack Quantum

• To warm up for jumping into the network world of OpenStack

OpenStack Admin Guide Chapter 7. Networking

• It is very important to take a look at this offical document first

Neurton Wiki

Architecture of Quantum Grizzly Release

• This contains the Quantum architecture in details

A Cisco Plugin Framework for Quantum L2 Network Overlays Spanning Multiple Physical Switches

• Cicso's Plugins are a little bit complicated because There are several versions those are different in the configuration and prerequisite.

Cisco Nexus Plug-in for OpenStack Neutron 

• Give a data sheet to list the functionality and feature it supports

What's new Neutron?

• Give a overall look of Neutron
• Another doc: http://www.slideshare.net/kamesh001/whats-new-in-neutron-for-open-stack-havana
• What components are in Neutron: http://www.slideshare.net/emaganap/open-stack-overview-meetups-oct-2013

Deep Dive into Neutron (Important)

• It is very technical to explain the the detail of code and message.

Open vSwitch in Neutron (Important)

• we can see how Open vSwitch is implemented in Neutron 

OpenStack Overview

• It introduces VM booting workflow with Nova and Networking
• Neurton deployment components

OPENSTACK QUANTUM (NEUTRON) PLUG-IN: THERE CAN ONLY BE ONE

• To explain why ML2 will come out

Modular Layer 2 in OpenStack Neutron

• New Feature: ToR Switch Control
• The video: http://www.youtube.com/watch?v=whmcQ-vHams

ML2

• Modular Layer 2 (ML2) The Modular Layer 2 (ML2) plugin is a new OpenSource plugin to Neutron. This plugin is a framework allowing OpenStack Networking to simultaneously utilize the variety of layer 2 networking technologies found in complex real-world data centers. It currently works with the existing Open vSwitch, Linux Bridge, and L2 agents. The ML2 plugin supports local, flat, VLAN, GRE and VXLAN network types via a type drivers and different mechanism drivers.

OVSDB User Guide

• OpenDaylight has OVSDB project that is related with ML2 plugin

Cisco OpenStack Overview

• Introduce Cisco Neutron Plugin
• Cisco Virtual Switch: Nexus 1000v
• Cisco UCSM

OpenStack Networking API v2.0 Reference

OpenStack RDO Deployment 

1. http://blog.csdn.net/cloudtech/article/details/19936249
2. http://blog.csdn.net/cloudtech/article/details/19936425
3. http://blog.csdn.net/cloudtech/article/details/19936487

OverStack over VXLAN

• https://wiki.openstack.org/wiki/Arista-neutron-ml2-driver
• Arista Related Information about Mechanism Driver
• https://blueprints.launchpad.net/neutron/+spec/arista-ml2-mechanism-driver
• http://www.bradreese.com/blog/4-1-2013-2.pdf
• https://docs.google.com/document/d/1efFprzY69h-vaikRE8hoGQuLzOzVNtyVZZLa2GHbXLI/edit

Developer Guide

How to write a Neutron Plugin

Neutron/LBaaS/PluginDrivers

http://www.slideshare.net/MiguelLavalle/network-virtualization-with-open-stack-quantum

[Thoughts] Cumulus Networks and Big Switch Networks

These two companies, Cumulus Networks and Big Switch Networks, are two of  my most favorite network companies in the world because they have a strong technical skill and creative ability/thought to build their networking products. Unfortunately, they walk in two different paths and directions. Big Switch Networks is based on OpenFlow but Cumulus Networks is not. For more information in details, please see below:

http://www.jedelman.com/1/post/2014/02/big-switch-cumulus-and-openflow.html
http://vimeo.com/87216036

[SDN} SDN Migration Use Cases

This document provides three migration use cases and I think they are very useful for those who work in networking field and are interested in SDN and need to take a look at. Here you go:
http://www.businesswire.com/news/home/20140211005653/en/Open-Networking-Foundation-Publishes-Open-SDN-Migration

[Thoughts] RESTful control of switches

OpenFlow is already the standard Southbound API in SDN field, but OpenFlow is the one of the many SouthBound approaches. In SDN solution, we don't necessarily need to use OpenFlow protocol to control data plane. RESTful API is another way to control or configure switches ( data plane ) if they supports. Arista Networks has provides Arista eAPI as RESTful control of switches. For more information in details, please refer to this article: http://blog.sflow.com/2013/08/restful-control-of-switches.html

[LXC] How to use LXC?

At the first glimpse, I was amazed by its way to provide a lightweight container in virtual environment. With shell scripts combining, we can use these to build a convenient and powerful automation solution to test all kind of programs that need multiple virtual machines within a server host ( at least my focus is on the automation test...XD ). There are already a bunch of articles to introduce LXC. Here I only list some common use commands for reference quickly:

# Install LXC
sudo apt-get install lxc

# Create a Linux Container named base ( -t: template, -n: namespace )
sudo lxc-create -t ubuntu -n base

# Start the Linux Container ( -d: daemon )
sudo lxc-start -n base -d

# Stop the Linux Container
sudo lxc-stop -n base

# List Linux Containers
lxc-ls --fancy

# Clone the Linux Container
lxc-clone -o base -n newvm1

# Access the container
lxc-console -n newvm1

# Shudown
lxc-shutdown -n test-container

# Destroy
lxc-destroy -n test-container


LXC can be controlled via Libvirt:
http://blog.scottlowe.org/2013/11/27/linux-containers-via-lxc-and-libvirt/

Exploring LXC Networking:

http://containerops.org/2013/11/19/lxc-networking/

Autostart

By default, containers will not be started after a reboot, even if they were running prior to the shutdown.
To make a container autostart, you simply need to symlink its config file into the /etc/lxc/auto directory:
ln -s /var/lib/lxc/test-container/config /etc/lxc/auto/test-container.conf

Reference:
https://www.digitalocean.com/community/articles/getting-started-with-lxc-on-an-ubuntu-13-04-vps
http://www.janoszen.com/2013/05/14/lxc-tutorial/

[Open vSwitch] The basic introduction of Open vSwitch

I post a slide to give a basic introduction of Open vSwitch. For the more in details, please check out the SlideShare URL as follows:
http://www.slideshare.net/teyenliu/the-basic-introduction-of-open-vswitch


Some Useful example of the OVS commands:
sudo ovs-vsctl show
sudo ovs-vsctl add-br mybridge
sudo ovs-vsctl del-br mybridge
sudo ovs-vsctl add-port mybridge port-name
sudo ovs-vsctl del-port mybridge port-name
sudo ovs-vsctl list Bridge/Port/Interface/...
sudo ovs-appctl fdb/show mybridge
sudo ovs-ofctl show mybridge
sudo ovs-ofctl dump-flows mybridge
sudo ovs-ofctl add-flow mybridge dl_src=02:a2:a2:a2:a2:a2,dl_dst=02:b2:b2:b2:b2:b2,in_port=2,dl_type=0x0800,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions=output:6
sudo ovs-ofctl del-flows mybridge dl_src=02:a2:a2:a2:a2:a2,dl_dst=02:b2:b2:b2:b2:b2,in_port=2,dl_type=0x0800,nw_src=10.0.0.1,nw_dst=10.0.0.2
sudo ovs-ofctl add-flow dp0 in_port=2,actions=output:6
# This will delete all the flow entries in the flow table
sudo ovs-ofctl del-flows mybridge

[GNS3] All the related URLs with GNS3 and Open vSwitch

To play with Openvswitch in GNS3, here is Openvswitch 1.2.2 installed on Microcore 4.0 Linux as Qemu image.
http://brezular.com/2013/09/17/linux-core-qemu-and-virtualbox-appliances-download/

Here are the installation steps.
http://brezular.com/2011/09/03/part1-openvswich-creating-and-submitting-openvswitch-extension-to-microcore-upstream/

And GNS3 labs are available here.
http://brezular.com/2011/06/25/part2-openvswich-vlans-trunks-l3-vlan-interface-intervlan-routing-configuration-and-testing/

[KVM and OVS] Installing KVM and Open vSwitch on Ubuntu

These articles provides a very good explanation about how to install KVM and Open vSwitch on Ubuntu.
http://blog.scottlowe.org/2012/08/17/installing-kvm-and-open-vswitch-on-ubuntu/
http://networkstatic.net/installing-open-vswitch-with-kvm/

I summarize the scripts from the above URLs as follows:

• ### Installing KVM and Open vSwitch on Ubuntu ###

sudo apt-get update && apt-get dist-upgrade

sudo apt-get install kvm qemu-kvm libvirt-bin virtinst virt-manager

sudo virsh net-destroy default

sudo virsh net-autostart --disable default

sudo aptitude purge ebtables

• ### Open vSwitch on Ubuntu ###

sudo apt-get install openvswitch-controller openvswitch-brcompat \

sudo openvswitch-switch openvswitch-datapath-source

# Edit this: /etc/default/openvswitch-switch and change this line:

  #BRCOMPAT=no ==> #BRCOMPAT=yes 

# to build and install the necessary module

sudo module-assistant auto-install openvswitch-datapath

• ### Add Open vSwitch bridge ###

sudo ovs-vsctl add-br br0
sudo ovs-vsctl add-port br0 eth0
sudo ovs-vsctl list port

• ### Change your eth0 IP to your new br0 interface ###

sudo ifconfig eth0 0
sudo ifconfig br0 192.168.1.x netmask 255.255.255.0
sudo route add default gw 192.168.1.1 br0

These two scripts bring up the KVM Tap interfaces into your
bridge from the CLI.

$ cat /etc/ovs-ifup
#!/bin/sh
switch='br0'
/sbin/ifconfig $1 0.0.0.0 up
ovs-vsctl add-port ${switch} $1

$ cat /etc/ovs-ifdown
#!/bin/sh
switch='br0'
/sbin/ifconfig $1 0.0.0.0 down
ovs-vsctl del-port ${switch} $1

#Then make executable
chmod +x /etc/ovs-ifup /etc/ovs-ifdown

• ### BOOT HD IMG ###

Here are some KVM examples. Starting with the CD is easiest. No build needed for testing.

sudo kvm -m 1024 -hda /media/Storage/imgs/centos.kvm -net nic,macaddr=00:11:22:CC:CC:C5 -net tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown &
OS Install

sudo kvm -m 512 -hda /media/Storage/imgs/centos.kvm -net nic,macaddr=00:11:22:CC:CC:C5 -net tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -cdrom /media/Storage/vm-images/CentOS-6.2-x86_64-LiveCD.iso &
CD Boot

sudo kvm -m 512 -net nic,macaddr=00:11:22:CC:CC:10 -net tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -cdrom /HD/Storage/vm-images/ubuntu-11.10-desktop-amd64.iso &
Make an Image from CD

sudo qemu-img create -f qcow2 /media/Storage/imgs/uCentOS-6.2.img 6G