ftp/session: use SESS_CLIENT instead of SESS_USER
ftp/display: make prompt message a parameter
ftp/net_connection: use state to check the net_connection

net_connection has a state field.

When it is CONN_CREATED, this means it works fine.
If this bit is not set, this means the connection couldn't be used.

And consolidate the return value.
When return 0, it means successful.
When return negative, it means fail.
ftp/session: add a field state to track session

The session has two state now: INITED UNINITED.

And consolidate the return value for functions.
0:        means successful
negative: means fail

NULL:     means fail
Non-NULL: means successful
ftp/makefile: add cscope as a target
ftp/README: add more detail in the design doc

Session: this is the top level idea. Each client has one session, while server
has several sessions.

Net_connection: its responsibility is to handle the network operations.
ftp/net_connection: add interface to destroy a connection

Also this enable to release the connection in the session.
ftp/net_connection: add net_ops in net_connection

The field net_ops enables the net_connection to have different way to
send/receive packets. And by default it is set to raw_tcp_ops.

From other module, it calls net_connection::net_conn_read(_write) to
receive/send packets.
ftp/session_client: initialize the net_ops of net_connection
kernel code test: fix char device

The original char device will fall into a infinit loop when read from it. This
is because the read function doesn't check the boundary.

This patch does this check to return when the offset is out of boundary and
update the offset with the number of bytes read.
kernel code test: reqest to load module

This is an interesting interface. So a module could ask kernel to load another
module.
kernel code reading: blk genhd

I guess the block layer is introduced from the hd.
kernel code reading: blk's elevator

Elevator is a kind of mechanism in block layer to optimize the IO.

Each request_queue will be assigned an elevator. From the request_queue point
of view, elevator is a helper to order its requests. When the someone ask the
request_queue for a request to process, the request_queue will ask the
elevator to give him one.

This is my point of view.
kernel code reading: blk core

blk_peek_request() and blk_fetch_request() are used to get a request from a
request_queue, while blk_fetch_request() return a request which could be
processed by LLD immediately.

generic_make_request() is the function which make a request witn a bio
structure.

To me, these two category just like producer and consumer. While for the
detail, I need to learn more.
kernel code test: kmem_cache mal-format of printk
kernel code test: mempool example

Some of the content is quoted from http://lwn.net/Articles/176750/.
While the mempool_create_kzalloc_pool() is removed from the tree.

Those APIs looks very self explain.
kernel code reading: how fdt work as a bridge between fw and kernel
kernel code reading: go through vfio_pci probe again

Like how vfio_pci is created, how vfio_group is created, how vfio_device is
added to a vfio_group.
go examples