a lot of bugfixes and package updates

6 files changed, 33856 insertions, 38 deletions

diff --git a/target/arm/uclibc-ng.config b/target/arm/uclibc-ng.config
index c012bd269..0c62a8e0a 100644
--- a/target/arm/uclibc-ng.config
+++ b/target/arm/uclibc-ng.config
@@ -53,7 +53,7 @@ UCLIBC_HAS_FLOATS=y
 UCLIBC_HAS_SOFT_FLOAT=y
 DO_C99_MATH=y
 # DO_XSI_MATH is not set
-UCLIBC_HAS_FENV=y
+# UCLIBC_HAS_FENV is not set
 KERNEL_HEADERS=""
 HAVE_DOT_CONFIG=y
 
diff --git a/target/linux/config/Config.in.audio b/target/linux/config/Config.in.audio
index 5fc901854..1e08c94b5 100644
--- a/target/linux/config/Config.in.audio
+++ b/target/linux/config/Config.in.audio
@@ -168,36 +168,36 @@ config ADK_KERNEL_SND_BCM2708_SOC_I2S
 config ADK_KERNEL_SND_BCM2708_SOC_HIFIBERRY_AMP
 	tristate "Hifiberry AMP"
 	select ADK_KERNEL_SND_BCM2708_SOC_I2S
-	depends on ADK_TARGET_BOARD_BCM28XX
+	depends on ADK_TARGET_BOARD_BCM28XX && ADK_KERNEL_VERSION_3_18
 
 config ADK_KERNEL_SND_BCM2708_SOC_HIFIBERRY_DAC
 	tristate "Hifiberry DAC"
 	select ADK_KERNEL_SND_BCM2708_SOC_I2S
 	select ADK_KERNEL_SND_SOC_PCM5102A
-	depends on ADK_TARGET_BOARD_BCM28XX
+	depends on ADK_TARGET_BOARD_BCM28XX && ADK_KERNEL_VERSION_3_18
 
 config ADK_KERNEL_SND_BCM2708_SOC_HIFIBERRY_DIGI
 	tristate "Hifiberry DIGI"
 	select ADK_KERNEL_SND_BCM2708_SOC_I2S
 	select ADK_KERNEL_SND_SOC_WM8804
-	depends on ADK_TARGET_BOARD_BCM28XX
+	depends on ADK_TARGET_BOARD_BCM28XX && ADK_KERNEL_VERSION_3_18
 
 config ADK_KERNEL_SND_BCM2708_SOC_RPI_DAC
 	tristate "RPI-DAC"
 	select ADK_KERNEL_SND_BCM2708_SOC_I2S
-	depends on ADK_TARGET_BOARD_BCM28XX
+	depends on ADK_TARGET_BOARD_BCM28XX && ADK_KERNEL_VERSION_3_18
 
 config ADK_KERNEL_SND_BCM2708_SOC_IQAUDIO_DAC
 	tristate "IQAudio-DAC"
 	select ADK_KERNEL_SND_BCM2708_SOC_I2S
 	select ADK_KERNEL_SND_SOC_PCM512x_I2C
-	depends on ADK_TARGET_BOARD_BCM28XX
+	depends on ADK_TARGET_BOARD_BCM28XX && ADK_KERNEL_VERSION_3_18
 
 config ADK_KERNEL_SND_BCM2708_SOC_RPI_PROTO
 	tristate "Rpi-Proto"
 	select ADK_KERNEL_SND_BCM2708_SOC_I2S
 	select ADK_KERNEL_SND_SOC_WM8731
-	depends on ADK_TARGET_BOARD_BCM28XX
+	depends on ADK_TARGET_BOARD_BCM28XX && ADK_KERNEL_VERSION_3_18
 
 config ADK_KERNEL_SND_IMX_SOC
 	bool "IMX6 SoC sound chip"
@@ -212,8 +212,7 @@ config ADK_KERNEL_SND_IMX_SOC
 	select ADK_KERNEL_SND_SOC_FSL_SPDIF
 	select ADK_KERNEL_REGMAP_SPI
 	select ADK_KERNEL_REGMAP_I2C
-	depends on ADK_TARGET_SYSTEM_SOLIDRUN_IMX6
-	depends on ADK_KERNEL_VERSION_3_14
+	depends on ADK_TARGET_SYSTEM_SOLIDRUN_IMX6 && ADK_KERNEL_VERSION_3_14
 	default y if ADK_TARGET_SYSTEM_SOLIDRUN_IMX6
 	default n
 
diff --git a/target/linux/config/Config.in.aufs b/target/linux/config/Config.in.aufs
index 2320cacd8..4e333d3a8 100644
--- a/target/linux/config/Config.in.aufs
+++ b/target/linux/config/Config.in.aufs
@@ -1,8 +1,7 @@
 menu "Overlay filesystems"
 
 config ADK_KERNEL_AUFS_FS
-	prompt "Aufs (Advanced multi layered unification filesystem) support"
-	tristate
+	bool "Aufs (Advanced multi layered unification filesystem) support"
 	help
 	  Aufs is a stackable unification filesystem such as Unionfs,
 	  which unifies several directories and provides a merged single
diff --git a/target/linux/config/Config.in.bluetooth b/target/linux/config/Config.in.bluetooth
index f9c8ea8b6..bcac0b0d0 100644
--- a/target/linux/config/Config.in.bluetooth
+++ b/target/linux/config/Config.in.bluetooth
@@ -1,9 +1,12 @@
 menu "Bluetooth support and drivers"
 depends on ADK_TARGET_WITH_USB || ADK_TARGET_WITH_MINIPCI || ADK_TARGET_WITH_SDIO
 
+config ADK_KERNEL_BT_BREDR
+	bool
+
 config ADK_KERNEL_BT
-	prompt "Bluetooth network stack"
-	tristate
+	tristate "Bluetooth network stack"
+	select ADK_KERNEL_BT_BREDR
 	default n
 	help
 	  Bluetooth is low-cost, low-power, short-range wireless technology.
@@ -23,8 +26,7 @@ config ADK_KERNEL_BT
 	     HIDP Module (Human Interface Device Protocol)
 
 config ADK_KERNEL_BT_L2CAP
-	prompt "L2CAP protocol support"
-	boolean
+	bool "L2CAP protocol support"
 	select ADK_KERNEL_BT
 	default n
 	help
@@ -32,10 +34,8 @@ config ADK_KERNEL_BT_L2CAP
 	  connection oriented and connection-less data transport.  L2CAP
 	  support is required for most Bluetooth applications.
 
-
 config ADK_KERNEL_BT_SCO
-	prompt "SCO link support"
-	boolean
+	bool "SCO link support"
 	select ADK_KERNEL_BT
 	default n
 	help
@@ -43,8 +43,7 @@ config ADK_KERNEL_BT_SCO
 	  required for voice applications like Headset and Audio.
 
 config ADK_KERNEL_BT_RFCOMM
-	prompt "RFCOMM protocol support"
-	tristate
+	tristate "RFCOMM protocol support"
 	select ADK_KERNEL_BT
 	depends on ADK_KERNEL_BT_L2CAP
 	default n
@@ -54,8 +53,7 @@ config ADK_KERNEL_BT_RFCOMM
 	  applications.
 
 config ADK_KERNEL_BT_BNEP
-	prompt "BNEP protocol support"
-	tristate
+	tristate "BNEP protocol support"
 	select ADK_KERNEL_BT
 	depends on ADK_KERNEL_BT_L2CAP
 	default n
@@ -65,8 +63,7 @@ config ADK_KERNEL_BT_BNEP
 	  Bluetooth PAN (Personal Area Network).
 
 config ADK_KERNEL_BT_HIDP
-	prompt "HIDP protocol support"
-	tristate
+	tristate "HIDP protocol support"
 	select ADK_KERNEL_INPUT
 	select ADK_KERNEL_HID
 	select ADK_KERNEL_BT
@@ -78,8 +75,7 @@ config ADK_KERNEL_BT_HIDP
 	  Interface Device Profile.
 
 config ADK_KERNEL_BT_HCIBTSDIO
-	prompt "HCI SDIO driver"
-	tristate
+	tristate "HCI SDIO driver"
 	select ADK_KERNEL_BT
 	depends on ADK_TARGET_WITH_SDIO
 	default n
@@ -89,8 +85,7 @@ config ADK_KERNEL_BT_HCIBTSDIO
 	  SDIO interface.
 
 config ADK_KERNEL_BT_HCIBTUSB
-	prompt "HCI USB driver"
-	tristate
+	tristate "HCI USB driver"
 	select ADK_KERNEL_BT
 	depends on ADK_TARGET_WITH_USB
 	default n
@@ -100,8 +95,7 @@ config ADK_KERNEL_BT_HCIBTUSB
 	  USB interface.
 
 config ADK_KERNEL_BT_HCIUART
-	prompt "HCI UART driver"
-	tristate
+	tristate "HCI UART driver"
 	select ADK_KERNEL_BT
 	default n
 	help
@@ -112,16 +106,14 @@ config ADK_KERNEL_BT_HCIUART
 	  adapter and BrainBoxes Bluetooth PC Card.
 
 config ADK_KERNEL_BT_MRVL
-	prompt "Marvell driver"
-	tristate
+	tristate "Marvell driver"
 	select ADK_KERNEL_BT
 	default n
 	help
 	  Bluetooth Marvell driver.
 
 config ADK_KERNEL_BT_MRVL_SDIO
-	prompt "Marvell SDIO driver"
-	tristate
+	tristate "Marvell SDIO driver"
 	select ADK_PACKAGE_BRCM_BLUETOOTH
 	select ADK_KERNEL_BT_MRVL
 	select ADK_KERNEL_BT_HCIBTSDIO
@@ -131,8 +123,7 @@ config ADK_KERNEL_BT_MRVL_SDIO
 	  Bluetooth Marvell driver.
 
 config ADK_KERNEL_BT_HCIBCM203X
-	prompt "HCI BCM203x USB driver"
-	tristate
+	tristate "HCI BCM203x USB driver"
 	select ADK_KERNEL_FW_LOADER
 	select ADK_KERNEL_BT_HCIBTUSB
 	select ADK_KERNEL_BT
@@ -144,8 +135,7 @@ config ADK_KERNEL_BT_HCIBCM203X
 	  Blutonium based devices.
 
 config ADK_KERNEL_BT_HCIBPA10X
-	prompt "HCI BPA10x USB driver"
-	tristate
+	tristate "HCI BPA10x USB driver"
 	select ADK_KERNEL_BT
 	select ADK_KERNEL_BT_HCIBTUSB
 	default n
diff --git a/target/linux/patches/4.0.4/aufs4.patch b/target/linux/patches/4.0.4/aufs4.patch
new file mode 100644
index 000000000..73b035010
--- /dev/null
+++ b/target/linux/patches/4.0.4/aufs4.patch
@@ -0,0 +1,33819 @@
+diff -Nur linux-4.0.4.orig/Documentation/ABI/testing/debugfs-aufs linux-4.0.4/Documentation/ABI/testing/debugfs-aufs
+--- linux-4.0.4.orig/Documentation/ABI/testing/debugfs-aufs	1970-01-01 01:00:00.000000000 +0100
++++ linux-4.0.4/Documentation/ABI/testing/debugfs-aufs	2015-05-30 22:11:30.000000000 +0200
+@@ -0,0 +1,50 @@
++What:		/debug/aufs/si_<id>/
++Date:		March 2009
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		Under /debug/aufs, a directory named si_<id> is created
++		per aufs mount, where <id> is a unique id generated
++		internally.
++
++What:		/debug/aufs/si_<id>/plink
++Date:		Apr 2013
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		It has three lines and shows the information about the
++		pseudo-link. The first line is a single number
++		representing a number of buckets. The second line is a
++		number of pseudo-links per buckets (separated by a
++		blank). The last line is a single number representing a
++		total number of psedo-links.
++		When the aufs mount option 'noplink' is specified, it
++		will show "1\n0\n0\n".
++
++What:		/debug/aufs/si_<id>/xib
++Date:		March 2009
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		It shows the consumed blocks by xib (External Inode Number
++		Bitmap), its block size and file size.
++		When the aufs mount option 'noxino' is specified, it
++		will be empty. About XINO files, see the aufs manual.
++
++What:		/debug/aufs/si_<id>/xino0, xino1 ... xinoN
++Date:		March 2009
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		It shows the consumed blocks by xino (External Inode Number
++		Translation Table), its link count, block size and file
++		size.
++		When the aufs mount option 'noxino' is specified, it
++		will be empty. About XINO files, see the aufs manual.
++
++What:		/debug/aufs/si_<id>/xigen
++Date:		March 2009
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		It shows the consumed blocks by xigen (External Inode
++		Generation Table), its block size and file size.
++		If CONFIG_AUFS_EXPORT is disabled, this entry will not
++		be created.
++		When the aufs mount option 'noxino' is specified, it
++		will be empty. About XINO files, see the aufs manual.
+diff -Nur linux-4.0.4.orig/Documentation/ABI/testing/sysfs-aufs linux-4.0.4/Documentation/ABI/testing/sysfs-aufs
+--- linux-4.0.4.orig/Documentation/ABI/testing/sysfs-aufs	1970-01-01 01:00:00.000000000 +0100
++++ linux-4.0.4/Documentation/ABI/testing/sysfs-aufs	2015-05-30 22:11:29.000000000 +0200
+@@ -0,0 +1,31 @@
++What:		/sys/fs/aufs/si_<id>/
++Date:		March 2009
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		Under /sys/fs/aufs, a directory named si_<id> is created
++		per aufs mount, where <id> is a unique id generated
++		internally.
++
++What:		/sys/fs/aufs/si_<id>/br0, br1 ... brN
++Date:		March 2009
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		It shows the abolute path of a member directory (which
++		is called branch) in aufs, and its permission.
++
++What:		/sys/fs/aufs/si_<id>/brid0, brid1 ... bridN
++Date:		July 2013
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		It shows the id of a member directory (which is called
++		branch) in aufs.
++
++What:		/sys/fs/aufs/si_<id>/xi_path
++Date:		March 2009
++Contact:	J. R. Okajima <hooanon05g@gmail.com>
++Description:
++		It shows the abolute path of XINO (External Inode Number
++		Bitmap, Translation Table and Generation Table) file
++		even if it is the default path.
++		When the aufs mount option 'noxino' is specified, it
++		will be empty. About XINO files, see the aufs manual.
+diff -Nur linux-4.0.4.orig/Documentation/filesystems/aufs/design/01intro.txt linux-4.0.4/Documentation/filesystems/aufs/design/01intro.txt
+--- linux-4.0.4.orig/Documentation/filesystems/aufs/design/01intro.txt	1970-01-01 01:00:00.000000000 +0100
++++ linux-4.0.4/Documentation/filesystems/aufs/design/01intro.txt	2015-05-30 22:11:30.000000000 +0200
+@@ -0,0 +1,157 @@
++
++# Copyright (C) 2005-2015 Junjiro R. Okajima
++
++Introduction
++----------------------------------------
++
++aufs [ei ju: ef es] | [a u f s]
++1. abbrev. for "advanced multi-layered unification filesystem".
++2. abbrev. for "another unionfs".
++3. abbrev. for "auf das" in German which means "on the" in English.
++   Ex. "Butter aufs Brot"(G) means "butter onto bread"(E).
++   But "Filesystem aufs Filesystem" is hard to understand.
++
++AUFS is a filesystem with features:
++- multi layered stackable unification filesystem, the member directory
++  is called as a branch.
++- branch permission and attribute, 'readonly', 'real-readonly',
++  'readwrite', 'whiteout-able', 'link-able whiteout', etc. and their
++  combination.
++- internal "file copy-on-write".
++- logical deletion, whiteout.
++- dynamic branch manipulation, adding, deleting and changing permission.
++- allow bypassing aufs, user's direct branch access.
++- external inode number translation table and bitmap which maintains the
++  persistent aufs inode number.
++- seekable directory, including NFS readdir.
++- file mapping, mmap and sharing pages.
++- pseudo-link, hardlink over branches.
++- loopback mounted filesystem as a branch.
++- several policies to select one among multiple writable branches.
++- revert a single systemcall when an error occurs in aufs.
++- and more...
++
++
++Multi Layered Stackable Unification Filesystem
++----------------------------------------------------------------------
++Most people already knows what it is.
++It is a filesystem which unifies several directories and provides a
++merged single directory. When users access a file, the access will be
++passed/re-directed/converted (sorry, I am not sure which English word is
++correct) to the real file on the member filesystem. The member
++filesystem is called 'lower filesystem' or 'branch' and has a mode
++'readonly' and 'readwrite.' And the deletion for a file on the lower
++readonly branch is handled by creating 'whiteout' on the upper writable
++branch.
++
++On LKML, there have been discussions about UnionMount (Jan Blunck,
++Bharata B Rao and Valerie Aurora) and Unionfs (Erez Zadok). They took
++different approaches to implement the merged-view.
++The former tries putting it into VFS, and the latter implements as a
++separate filesystem.
++(If I misunderstand about these implementations, please let me know and
++I shall correct it. Because it is a long time ago when I read their
++source files last time).
++
++UnionMount's approach will be able to small, but may be hard to share
++branches between several UnionMount since the whiteout in it is
++implemented in the inode on branch filesystem and always
++shared. According to Bharata's post, readdir does not seems to be
++finished yet.
++There are several missing features known in this implementations such as
++- for users, the inode number may change silently. eg. copy-up.
++- link(2) may break by copy-up.
++- read(2) may get an obsoleted filedata (fstat(2) too).
++- fcntl(F_SETLK) may be broken by copy-up.
++- unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after
++  open(O_RDWR).
++
++In linux-3.18, "overlay" filesystem (formerly known as "overlayfs") was
++merged into mainline. This is another implementation of UnionMount as a
++separated filesystem. All the limitations and known problems which
++UnionMount are equally inherited to "overlay" filesystem.
++
++Unionfs has a longer history. When I started implementing a stackable
++filesystem (Aug 2005), it already existed. It has virtual super_block,
++inode, dentry and file objects and they have an array pointing lower
++same kind objects. After contributing many patches for Unionfs, I
++re-started my project AUFS (Jun 2006).
++
++In AUFS, the structure of filesystem resembles to Unionfs, but I
++implemented my own ideas, approaches and enhancements and it became
++totally different one.
++
++Comparing DM snapshot and fs based implementation
++- the number of bytes to be copied between devices is much smaller.
++- the type of filesystem must be one and only.
++- the fs must be writable, no readonly fs, even for the lower original
++  device. so the compression fs will not be usable. but if we use
++  loopback mount, we may address this issue.
++  for instance,
++	mount /cdrom/squashfs.img /sq
++	losetup /sq/ext2.img
++	losetup /somewhere/cow
++	dmsetup "snapshot /dev/loop0 /dev/loop1 ..."
++- it will be difficult (or needs more operations) to extract the
++  difference between the original device and COW.
++- DM snapshot-merge may help a lot when users try merging. in the
++  fs-layer union, users will use rsync(1).
++
++You may want to read my old paper "Filesystems in LiveCD"
++(http://aufs.sourceforge.net/aufs2/report/sq/sq.pdf).
++
++
++Several characters/aspects/persona of aufs
++----------------------------------------------------------------------
++
++Aufs has several characters, aspects or persona.
++1. a filesystem, callee of VFS helper
++2. sub-VFS, caller of VFS helper for branches
++3. a virtual filesystem which maintains persistent inode number
++4. reader/writer of files on branches such like an application
++
++1. Callee of VFS Helper
++As an ordinary linux filesystem, aufs is a callee of VFS. For instance,
++unlink(2) from an application reaches sys_unlink() kernel function and
++then vfs_unlink() is called. vfs_unlink() is one of VFS helper and it
++calls filesystem specific unlink operation. Actually aufs implements the
++unlink operation but it behaves like a redirector.
++
++2. Caller of VFS Helper for Branches
++aufs_unlink() passes the unlink request to the branch filesystem as if
++it were called from VFS. So the called unlink operation of the branch
++filesystem acts as usual. As a caller of VFS helper, aufs should handle
++every necessary pre/post operation for the branch filesystem.
++- acquire the lock for the parent dir on a branch
++- lookup in a branch
++- revalidate dentry on a branch
++- mnt_want_write() for a branch
++- vfs_unlink() for a branch
++- mnt_drop_write() for a branch
++- release the lock on a branch
++
++3. Persistent Inode Number
++One of the most important issue for a filesystem is to maintain inode
++numbers. This is particularly important to support exporting a
++filesystem via NFS. Aufs is a virtual filesystem which doesn't have a
++backend block device for its own. But some storage is necessary to
++keep and maintain the inode numbers. It may be a large space and may not
++suit to keep in memory. Aufs rents some space from its first writable
++branch filesystem (by default) and creates file(s) on it. These files
++are created by aufs internally and removed soon (currently) keeping
++opened.
++Note: Because these files are removed, they are totally gone after
++      unmounting aufs. It means the inode numbers are not persistent
++      across unmount or reboot. I have a plan to make them really
++      persistent which will be important for aufs on NFS server.
++
++4. Read/Write Files Internally (copy-on-write)
++Because a branch can be readonly, when you write a file on it, aufs will
++"copy-up" it to the upper writable branch internally. And then write the
++originally requested thing to the file. Generally kernel doesn't
++open/read/write file actively. In aufs, even a single write may cause a
++internal "file copy". This behaviour is very similar to cp(1) command.
++
++Some people may think it is better to pass such work to user space
++helper, instead of doing in kernel space. Actually I am still thinking
++about it. But currently I have implemented it in kernel space.
+diff -Nur linux-4.0.4.orig/Documentation/filesystems/aufs/design/02struct.txt linux-4.0.4/Documentation/filesystems/aufs/design/02struct.txt
+--- linux-4.0.4.orig/Documentation/filesystems/aufs/design/02struct.txt	1970-01-01 01:00:00.000000000 +0100
++++ linux-4.0.4/Documentation/filesystems/aufs/design/02struct.txt	2015-05-30 22:11:30.000000000 +0200
+@@ -0,0 +1,245 @@
++
++# Copyright (C) 2005-2015 Junjiro R. Okajima
++
++Basic Aufs Internal Structure
++
++Superblock/Inode/Dentry/File Objects
++----------------------------------------------------------------------
++As like an ordinary filesystem, aufs has its own
++superblock/inode/dentry/file objects. All these objects have a
++dynamically allocated array and store the same kind of pointers to the
++lower filesystem, branch.
++For example, when you build a union with one readwrite branch and one
++readonly, mounted /au, /rw and /ro respectively.
++- /au = /rw + /ro
++- /ro/fileA exists but /rw/fileA
++
++Aufs lookup operation finds /ro/fileA and gets dentry for that. These
++pointers are stored in a aufs dentry. The array in aufs dentry will be,
++- [0] = NULL (because /rw/fileA doesn't exist)
++- [1] = /ro/fileA
++
++This style of an array is essentially same to the aufs
++superblock/inode/dentry/file objects.
++
++Because aufs supports manipulating branches, ie. add/delete/change
++branches dynamically, these objects has its own generation. When
++branches are changed, the generation in aufs superblock is
++incremented. And a generation in other object are compared when it is
++accessed. When a generation in other objects are obsoleted, aufs
++refreshes the internal array.
++
++
++Superblock
++----------------------------------------------------------------------
++Additionally aufs superblock has some data for policies to select one
++among multiple writable branches, XIB files, pseudo-links and kobject.
++See below in detail.
++About the policies which supports copy-down a directory, see
++wbr_policy.txt too.
++
++
++Branch and XINO(External Inode Number Translation Table)
++----------------------------------------------------------------------
++Every branch has its own xino (external inode number translation table)
++file. The xino file is created and unlinked by aufs internally. When two
++members of a union exist on the same filesystem, they share the single
++xino file.
++The struct of a xino file is simple, just a sequence of aufs inode
++numbers which is indexed by the lower inode number.
++In the above sample, assume the inode number of /ro/fileA is i111 and
++aufs assigns the inode number i999 for fileA. Then aufs writes 999 as
++4(8) bytes at 111 * 4(8) bytes offset in the xino file.
++
++When the inode numbers are not contiguous, the xino file will be sparse
++which has a hole in it and doesn't consume as much disk space as it
++might appear. If your branch filesystem consumes disk space for such
++holes, then you should specify 'xino=' option at mounting aufs.
++
++Aufs has a mount option to free the disk blocks for such holes in XINO
++files on tmpfs or ramdisk. But it is not so effective actually. If you
++meet a problem of disk shortage due to XINO files, then you should try
++"tmpfs-ino.patch" (and "vfs-ino.patch" too) in aufs4-standalone.git.
++The patch localizes the assignment inumbers per tmpfs-mount and avoid
++the holes in XINO files.
++
++Also a writable branch has three kinds of "whiteout bases". All these
++are existed when the branch is joined to aufs, and their names are
++whiteout-ed doubly, so that users will never see their names in aufs
++hierarchy.
++1. a regular file which will be hardlinked to all whiteouts.
++2. a directory to store a pseudo-link.
++3. a directory to store an "orphan"-ed file temporary.
++
++1. Whiteout Base
++   When you remove a file on a readonly branch, aufs handles it as a
++   logical deletion and creates a whiteout on the upper writable branch
++   as a hardlink of this file in order not to consume inode on the
++   writable branch.
++2. Pseudo-link Dir
++   See below, Pseudo-link.
++3. Step-Parent Dir
++   When "fileC" exists on the lower readonly branch only and it is
++   opened and removed with its parent dir, and then user writes
++   something into it, then aufs copies-up fileC to this
++   directory. Because there is no other dir to store fileC. After
++   creating a file under this dir, the file is unlinked.
++
++Because aufs supports manipulating branches, ie. add/delete/change
++dynamically, a branch has its own id. When the branch order changes,
++aufs finds the new index by searching the branch id.
++
++
++Pseudo-link
++----------------------------------------------------------------------
++Assume "fileA" exists on the lower readonly branch only and it is
++hardlinked to "fileB" on the branch. When you write something to fileA,
++aufs copies-up it to the upper writable branch. Additionally aufs
++creates a hardlink under the Pseudo-link Directory of the writable
++branch. The inode of a pseudo-link is kept in aufs super_block as a
++simple list. If fileB is read after unlinking fileA, aufs returns
++filedata from the pseudo-link instead of the lower readonly
++branch. Because the pseudo-link is based upon the inode, to keep the
++inode number by xino (see above) is essentially necessary.
++
++All the hardlinks under the Pseudo-link Directory of the writable branch
++should be restored in a proper location later. Aufs provides a utility
++to do this. The userspace helpers executed at remounting and unmounting
++aufs by default.
++During this utility is running, it puts aufs into the pseudo-link
++maintenance mode. In this mode, only the process which began the
++maintenance mode (and its child processes) is allowed to operate in
++aufs. Some other processes which are not related to the pseudo-link will
++be allowed to run too, but the rest have to return an error or wait
++until the maintenance mode ends. If a process already acquires an inode
++mutex (in VFS), it has to return an error.
++
++
++XIB(external inode number bitmap)
++----------------------------------------------------------------------
++Addition to the xino file per a branch, aufs has an external inode number
++bitmap in a superblock object. It is also an internal file such like a
++xino file.
++It is a simple bitmap to mark whether the aufs inode number is in-use or
++not.
++To reduce the file I/O, aufs prepares a single memory page to cache xib.
++
++As well as XINO files, aufs has a feature to truncate/refresh XIB to
++reduce the number of consumed disk blocks for these files.
++
++
++Virtual or Vertical Dir, and Readdir in Userspace
++----------------------------------------------------------------------
++In order to support multiple layers (branches), aufs readdir operation
++constructs a virtual dir block on memory. For readdir, aufs calls
++vfs_readdir() internally for each dir on branches, merges their entries
++with eliminating the whiteout-ed ones, and sets it to file (dir)
++object. So the file object has its entry list until it is closed. The
++entry list will be updated when the file position is zero and becomes
++obsoleted. This decision is made in aufs automatically.
++
++The dynamically allocated memory block for the name of entries has a
++unit of 512 bytes (by default) and stores the names contiguously (no
++padding). Another block for each entry is handled by kmem_cache too.
++During building dir blocks, aufs creates hash list and judging whether
++the entry is whiteouted by its upper branch or already listed.
++The merged result is cached in the corresponding inode object and
++maintained by a customizable life-time option.
++
++Some people may call it can be a security hole or invite DoS attack
++since the opened and once readdir-ed dir (file object) holds its entry
++list and becomes a pressure for system memory. But I'd say it is similar
++to files under /proc or /sys. The virtual files in them also holds a
++memory page (generally) while they are opened. When an idea to reduce
++memory for them is introduced, it will be applied to aufs too.
++For those who really hate this situation, I've developed readdir(3)
++library which operates this merging in userspace. You just need to set
++LD_PRELOAD environment variable, and aufs will not consume no memory in
++kernel space for readdir(3).
++
++
++Workqueue
++----------------------------------------------------------------------
++Aufs sometimes requires privilege access to a branch. For instance,
++in copy-up/down operation. When a user process is going to make changes
++to a file which exists in the lower readonly branch only, and the mode
++of one of ancestor directories may not be writable by a user
++process. Here aufs copy-up the file with its ancestors and they may
++require privilege to set its owner/group/mode/etc.
++This is a typical case of a application character of aufs (see
++Introduction).
++
++Aufs uses workqueue synchronously for this case. It creates its own
++workqueue. The workqueue is a kernel thread and has privilege. Aufs
++passes the request to call mkdir or write (for example), and wait for
++its completion. This approach solves a problem of a signal handler
++simply.
++If aufs didn't adopt the workqueue and changed the privilege of the
++process, then the process may receive the unexpected SIGXFSZ or other
++signals.
++
++Also aufs uses the system global workqueue ("events" kernel thread) too
++for asynchronous tasks, such like handling inotify/fsnotify, re-creating a
++whiteout base and etc. This is unrelated to a privilege.
++Most of aufs operation tries acquiring a rw_semaphore for aufs
++superblock at the beginning, at the same time waits for the completion
++of all queued asynchronous tasks.
++
++
++Whiteout
++----------------------------------------------------------------------
++The whiteout in aufs is very similar to Unionfs's. That is represented
++by its filename. UnionMount takes an approach of a file mode, but I am
++afraid several utilities (find(1) or something) will have to support it.
++
++Basically the whiteout represents "logical deletion" which stops aufs to
++lookup further, but also it represents "dir is opaque" which also stop
++further lookup.
++
++In aufs, rmdir(2) and rename(2) for dir uses whiteout alternatively.
++In order to make several functions in a single systemcall to be
++revertible, aufs adopts an approach to rename a directory to a temporary
++unique whiteouted name.
++For example, in rename(2) dir where the target dir already existed, aufs
++renames the target dir to a temporary unique whiteouted name before the
++actual rename on a branch, and then handles other actions (make it opaque,
++update the attributes, etc). If an error happens in these actions, aufs
++simply renames the whiteouted name back and returns an error. If all are
++succeeded, aufs registers a function to remove the whiteouted unique
++temporary name completely and asynchronously to the system global
++workqueue.
++
++
++Copy-up
++----------------------------------------------------------------------
++It is a well-known feature or concept.
++When user modifies a file on a readonly branch, aufs operate "copy-up"
++internally and makes change to the new file on the upper writable branch.
++When the trigger systemcall does not update the timestamps of the parent
++dir, aufs reverts it after copy-up.
++
++
++Move-down (aufs3.9 and later)
++----------------------------------------------------------------------
++"Copy-up" is one of the essential feature in aufs. It copies a file from
++the lower readonly branch to the upper writable branch when a user
++changes something about the file.
++"Move-down" is an opposite action of copy-up. Basically this action is
++ran manually instead of automatically and internally.
++For desgin and implementation, aufs has to consider these issues.
++- whiteout for the file may exist on the lower branch.
++- ancestor directories may not exist on the lower branch.
++- diropq for the ancestor directories may exist on the upper branch.
++- free space on the lower branch will reduce.
++- another access to the file may happen during moving-down, including
++  UDBA (see "Revalidate Dentry and UDBA").
++- the file should not be hard-linked nor pseudo-linked. they should be
++  handled by auplink utility later.
++
++Sometimes users want to move-down a file from the upper writable branch
++to the lower readonly or writable branch. For instance,
++- the free space of the upper writable branch is going to run out.
++- create a new intermediate branch between the upper and lower branch.
++- etc.
++
++For this purpose, use "aumvdown" command in aufs-util.git.
+diff -Nur linux-4.0.4.orig/Documentation/filesystems/aufs/design/03atomic_open.txt linux-4.0.4/Documentation/filesystems/aufs/design/03atomic_open.txt
+--- linux-4.0.4.orig/Documentation/filesystems/aufs/design/03atomic_open.txt	1970-01-01 01:00:00.000000000 +0100
++++ linux-4.0.4/Documentation/filesystems/aufs/design/03atomic_open.txt	2015-05-30 22:11:31.000000000 +0200
+@@ -0,0 +1,72 @@
++
++# Copyright (C) 2015 Junjiro R. Okajima
++
++Support for a branch who has its ->atomic_open()
++----------------------------------------------------------------------
++The filesystems who implement its ->atomic_open() are not majority. For
++example NFSv4 does, and aufs should call NFSv4 ->atomic_open,
++particularly for open(O_CREAT|O_EXCL, 0400) case. Other than
++->atomic_open(), NFSv4 returns an error for this open(2). While I am not
++sure whether all filesystems who have ->atomic_open() behave like this,
++but NFSv4 surely returns the error.
++
++In order to support ->atomic_open() for aufs, there are a few
++approaches.
++
++A. Introduce aufs_atomic_open()
++   - calls one of VFS:do_last(), lookup_open() or atomic_open() for
++     branch fs.
++B. Introduce aufs_atomic_open() calling create, open and chmod. this is
++   an aufs user Pip Cet's approach
++   - calls aufs_create(), VFS finish_open() and notify_change().
++   - pass fake-mode to finish_open(), and then correct the mode by
++     notify_change().
++C. Extend aufs_open() to call branch fs's ->atomic_open()
++   - no aufs_atomic_open().
++   - aufs_lookup() registers the TID to an aufs internal object.
++   - aufs_create() does nothing when the matching TID is registered, but
++     registers the mode.
++   - aufs_open() calls branch fs's ->atomic_open() when the matching
++     TID is registered.
++D. Extend aufs_open() to re-try branch fs's ->open() with superuser's
++   credential
++   - no aufs_atomic_open().
++   - aufs_create() registers the TID to an internal object. this info
++     represents "this process created this file just now."
++   - when aufs gets EACCES from branch fs's ->open(), then confirm the
++     registered TID and re-try open() with superuser's credential.
++
++Pros and cons for each approach.
++
++A.
++   - straightforward but highly depends upon VFS internal.
++   - the atomic behavaiour is kept.
++   - some of parameters such as nameidata are hard to reproduce for
++     branch fs.
++   - large overhead.
++B.
++   - easy to implement.
++   - the atomic behavaiour is lost.
++C.
++   - the atomic behavaiour is kept.
++   - dirty and tricky.
++   - VFS checks whether the file is created correctly after calling
++     ->create(), which means this approach doesn't work.
++D.
++   - easy to implement.
++   - the atomic behavaiour is lost.
++   - to open a file with superuser's credential and give it to a user
++     process is a bad idea, since the file object keeps the credential
++     in it. It may affect LSM or something. This approach doesn't work
++     either.
++
++The approach A is ideal, but it hard to implement. So here is a
++variation of A, which is to be implemented.
++
++A-1. Introduce aufs_atomic_open()
++     - calls branch fs ->atomic_open() if exists. otherwise calls
++       vfs_create() and finish_open().
++     - the demerit is that the several checks after branch fs
++       ->atomic_open() are lost. in the ordinary case, the checks are
++       done by VFS:do_last(), lookup_open() and atomic_open(). some can
++       be implemented in aufs, but not all I am afraid.
+diff -Nur linux-4.0.4.orig/Documentation/filesystems/aufs/design/03lookup.txt linux-4.0.4/Documentation/filesystems/aufs/design/03lookup.txt
+--- linux-4.0.4.orig/Documentation/filesystems/aufs/design/03lookup.txt	1970-01-01 01:00:00.000000000 +0100
++++ linux-4.0.4/Documentation/filesystems/aufs/design/03lookup.txt	2015-05-30 22:11:30.000000000 +0200
+@@ -0,0 +1,100 @@
++
++# Copyright (C) 2005-2015 Junjiro R. Okajima
++
++Lookup in a Branch
++----------------------------------------------------------------------
++Since aufs has a character of sub-VFS (see Introduction), it operates
++lookup for branches as VFS does. It may be a heavy work. But almost all
++lookup operation in aufs is the simplest case, ie. lookup only an entry
++directly connected to its parent. Digging down the directory hierarchy
++is unnecessary. VFS has a function lookup_one_len() for that use, and
++aufs calls it.
++
++When a branch is a remote filesystem, aufs basically relies upon its
++->d_revalidate(), also aufs forces the hardest revalidate tests for
++them.
++For d_revalidate, aufs implements three levels of revalidate tests. See
++"Revalidate Dentry and UDBA" in detail.
++
++
++Test Only the Highest One for the Directory Permission (dirperm1 option)
++----------------------------------------------------------------------
++Let's try case study.
++- aufs has two branches, upper readwrite and lower readonly.
++  /au = /rw + /ro
++- "dirA" exists under /ro, but /rw. and its mode is 0700.
++- user invoked "chmod a+rx /au/dirA"
++- the internal copy-up is activated and "/rw/dirA" is created and its
++  permission bits are set to world readable.
++- then "/au/dirA" becomes world readable?
++
++In this case, /ro/dirA is still 0700 since it exists in readonly branch,
++or it may be a natively readonly filesystem. If aufs respects the lower
++branch, it should not respond readdir request from other users. But user
++allowed it by chmod. Should really aufs rejects showing the entries
++under /ro/dirA?
++
++To be honest, I don't have a good solution for this case. So aufs
++implements 'dirperm1' and 'nodirperm1' mount options, and leave it to
++users.
++When dirperm1 is specified, aufs checks only the highest one for the
++directory permission, and shows the entries. Otherwise, as usual, checks
++every dir existing on all branches and rejects the request.
++
++As a side effect, dirperm1 option improves the performance of aufs
++because the number of permission check is reduced when the number