From 66f2a122c68d8f13e5db978b6b7571aaf0e53a19 Mon Sep 17 00:00:00 2001 From: "Matthew Wilcox (Oracle)" Date: Tue, 2 Jul 2019 13:54:38 -0400 Subject: docs: Move binderfs to admin-guide The documentation is more appropriate for the administrator than for the internal kernel API section it is currently in. Signed-off-by: Matthew Wilcox (Oracle) Acked-by: Christian Brauner Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/binderfs.rst | 68 ++++++++++++++++++++++++++++++++++ Documentation/admin-guide/index.rst | 1 + Documentation/filesystems/binderfs.rst | 68 ---------------------------------- Documentation/filesystems/index.rst | 10 ----- 4 files changed, 69 insertions(+), 78 deletions(-) create mode 100644 Documentation/admin-guide/binderfs.rst delete mode 100644 Documentation/filesystems/binderfs.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/binderfs.rst b/Documentation/admin-guide/binderfs.rst new file mode 100644 index 000000000000..c009671f8434 --- /dev/null +++ b/Documentation/admin-guide/binderfs.rst @@ -0,0 +1,68 @@ +.. SPDX-License-Identifier: GPL-2.0 + +The Android binderfs Filesystem +=============================== + +Android binderfs is a filesystem for the Android binder IPC mechanism. It +allows to dynamically add and remove binder devices at runtime. Binder devices +located in a new binderfs instance are independent of binder devices located in +other binderfs instances. Mounting a new binderfs instance makes it possible +to get a set of private binder devices. + +Mounting binderfs +----------------- + +Android binderfs can be mounted with:: + + mkdir /dev/binderfs + mount -t binder binder /dev/binderfs + +at which point a new instance of binderfs will show up at ``/dev/binderfs``. +In a fresh instance of binderfs no binder devices will be present. There will +only be a ``binder-control`` device which serves as the request handler for +binderfs. Mounting another binderfs instance at a different location will +create a new and separate instance from all other binderfs mounts. This is +identical to the behavior of e.g. ``devpts`` and ``tmpfs``. The Android +binderfs filesystem can be mounted in user namespaces. + +Options +------- +max + binderfs instances can be mounted with a limit on the number of binder + devices that can be allocated. The ``max=`` mount option serves as + a per-instance limit. If ``max=`` is set then only ```` number + of binder devices can be allocated in this binderfs instance. + +Allocating binder Devices +------------------------- + +.. _ioctl: http://man7.org/linux/man-pages/man2/ioctl.2.html + +To allocate a new binder device in a binderfs instance a request needs to be +sent through the ``binder-control`` device node. A request is sent in the form +of an `ioctl() `_. + +What a program needs to do is to open the ``binder-control`` device node and +send a ``BINDER_CTL_ADD`` request to the kernel. Users of binderfs need to +tell the kernel which name the new binder device should get. By default a name +can only contain up to ``BINDERFS_MAX_NAME`` chars including the terminating +zero byte. + +Once the request is made via an `ioctl() `_ passing a ``struct +binder_device`` with the name to the kernel it will allocate a new binder +device and return the major and minor number of the new device in the struct +(This is necessary because binderfs allocates a major device number +dynamically.). After the `ioctl() `_ returns there will be a new +binder device located under /dev/binderfs with the chosen name. + +Deleting binder Devices +----------------------- + +.. _unlink: http://man7.org/linux/man-pages/man2/unlink.2.html +.. _rm: http://man7.org/linux/man-pages/man1/rm.1.html + +Binderfs binder devices can be deleted via `unlink() `_. This means +that the `rm() `_ tool can be used to delete them. Note that the +``binder-control`` device cannot be deleted since this would make the binderfs +instance unuseable. The ``binder-control`` device will be deleted when the +binderfs instance is unmounted and all references to it have been dropped. diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 8001917ee012..24fbe0568eff 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -70,6 +70,7 @@ configure specific aspects of kernel behavior to your liking. ras bcache ext4 + binderfs pm/index thunderbolt LSM/index diff --git a/Documentation/filesystems/binderfs.rst b/Documentation/filesystems/binderfs.rst deleted file mode 100644 index c009671f8434..000000000000 --- a/Documentation/filesystems/binderfs.rst +++ /dev/null @@ -1,68 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -The Android binderfs Filesystem -=============================== - -Android binderfs is a filesystem for the Android binder IPC mechanism. It -allows to dynamically add and remove binder devices at runtime. Binder devices -located in a new binderfs instance are independent of binder devices located in -other binderfs instances. Mounting a new binderfs instance makes it possible -to get a set of private binder devices. - -Mounting binderfs ------------------ - -Android binderfs can be mounted with:: - - mkdir /dev/binderfs - mount -t binder binder /dev/binderfs - -at which point a new instance of binderfs will show up at ``/dev/binderfs``. -In a fresh instance of binderfs no binder devices will be present. There will -only be a ``binder-control`` device which serves as the request handler for -binderfs. Mounting another binderfs instance at a different location will -create a new and separate instance from all other binderfs mounts. This is -identical to the behavior of e.g. ``devpts`` and ``tmpfs``. The Android -binderfs filesystem can be mounted in user namespaces. - -Options -------- -max - binderfs instances can be mounted with a limit on the number of binder - devices that can be allocated. The ``max=`` mount option serves as - a per-instance limit. If ``max=`` is set then only ```` number - of binder devices can be allocated in this binderfs instance. - -Allocating binder Devices -------------------------- - -.. _ioctl: http://man7.org/linux/man-pages/man2/ioctl.2.html - -To allocate a new binder device in a binderfs instance a request needs to be -sent through the ``binder-control`` device node. A request is sent in the form -of an `ioctl() `_. - -What a program needs to do is to open the ``binder-control`` device node and -send a ``BINDER_CTL_ADD`` request to the kernel. Users of binderfs need to -tell the kernel which name the new binder device should get. By default a name -can only contain up to ``BINDERFS_MAX_NAME`` chars including the terminating -zero byte. - -Once the request is made via an `ioctl() `_ passing a ``struct -binder_device`` with the name to the kernel it will allocate a new binder -device and return the major and minor number of the new device in the struct -(This is necessary because binderfs allocates a major device number -dynamically.). After the `ioctl() `_ returns there will be a new -binder device located under /dev/binderfs with the chosen name. - -Deleting binder Devices ------------------------ - -.. _unlink: http://man7.org/linux/man-pages/man2/unlink.2.html -.. _rm: http://man7.org/linux/man-pages/man1/rm.1.html - -Binderfs binder devices can be deleted via `unlink() `_. This means -that the `rm() `_ tool can be used to delete them. Note that the -``binder-control`` device cannot be deleted since this would make the binderfs -instance unuseable. The ``binder-control`` device will be deleted when the -binderfs instance is unmounted and all references to it have been dropped. diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 1651173f1118..2de2fe2ab078 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -32,13 +32,3 @@ filesystem implementations. journalling fscrypt - -Filesystem-specific documentation -================================= - -Documentation for individual filesystem types can be found here. - -.. toctree:: - :maxdepth: 2 - - binderfs -- cgit v1.2.3