1*4882a593Smuzhiyun.. SPDX-License-Identifier: GPL-2.0 2*4882a593Smuzhiyun 3*4882a593SmuzhiyunThe Android binderfs Filesystem 4*4882a593Smuzhiyun=============================== 5*4882a593Smuzhiyun 6*4882a593SmuzhiyunAndroid binderfs is a filesystem for the Android binder IPC mechanism. It 7*4882a593Smuzhiyunallows to dynamically add and remove binder devices at runtime. Binder devices 8*4882a593Smuzhiyunlocated in a new binderfs instance are independent of binder devices located in 9*4882a593Smuzhiyunother binderfs instances. Mounting a new binderfs instance makes it possible 10*4882a593Smuzhiyunto get a set of private binder devices. 11*4882a593Smuzhiyun 12*4882a593SmuzhiyunMounting binderfs 13*4882a593Smuzhiyun----------------- 14*4882a593Smuzhiyun 15*4882a593SmuzhiyunAndroid binderfs can be mounted with:: 16*4882a593Smuzhiyun 17*4882a593Smuzhiyun mkdir /dev/binderfs 18*4882a593Smuzhiyun mount -t binder binder /dev/binderfs 19*4882a593Smuzhiyun 20*4882a593Smuzhiyunat which point a new instance of binderfs will show up at ``/dev/binderfs``. 21*4882a593SmuzhiyunIn a fresh instance of binderfs no binder devices will be present. There will 22*4882a593Smuzhiyunonly be a ``binder-control`` device which serves as the request handler for 23*4882a593Smuzhiyunbinderfs. Mounting another binderfs instance at a different location will 24*4882a593Smuzhiyuncreate a new and separate instance from all other binderfs mounts. This is 25*4882a593Smuzhiyunidentical to the behavior of e.g. ``devpts`` and ``tmpfs``. The Android 26*4882a593Smuzhiyunbinderfs filesystem can be mounted in user namespaces. 27*4882a593Smuzhiyun 28*4882a593SmuzhiyunOptions 29*4882a593Smuzhiyun------- 30*4882a593Smuzhiyunmax 31*4882a593Smuzhiyun binderfs instances can be mounted with a limit on the number of binder 32*4882a593Smuzhiyun devices that can be allocated. The ``max=<count>`` mount option serves as 33*4882a593Smuzhiyun a per-instance limit. If ``max=<count>`` is set then only ``<count>`` number 34*4882a593Smuzhiyun of binder devices can be allocated in this binderfs instance. 35*4882a593Smuzhiyun 36*4882a593Smuzhiyunstats 37*4882a593Smuzhiyun Using ``stats=global`` enables global binder statistics. 38*4882a593Smuzhiyun ``stats=global`` is only available for a binderfs instance mounted in the 39*4882a593Smuzhiyun initial user namespace. An attempt to use the option to mount a binderfs 40*4882a593Smuzhiyun instance in another user namespace will return a permission error. 41*4882a593Smuzhiyun 42*4882a593SmuzhiyunAllocating binder Devices 43*4882a593Smuzhiyun------------------------- 44*4882a593Smuzhiyun 45*4882a593Smuzhiyun.. _ioctl: http://man7.org/linux/man-pages/man2/ioctl.2.html 46*4882a593Smuzhiyun 47*4882a593SmuzhiyunTo allocate a new binder device in a binderfs instance a request needs to be 48*4882a593Smuzhiyunsent through the ``binder-control`` device node. A request is sent in the form 49*4882a593Smuzhiyunof an `ioctl() <ioctl_>`_. 50*4882a593Smuzhiyun 51*4882a593SmuzhiyunWhat a program needs to do is to open the ``binder-control`` device node and 52*4882a593Smuzhiyunsend a ``BINDER_CTL_ADD`` request to the kernel. Users of binderfs need to 53*4882a593Smuzhiyuntell the kernel which name the new binder device should get. By default a name 54*4882a593Smuzhiyuncan only contain up to ``BINDERFS_MAX_NAME`` chars including the terminating 55*4882a593Smuzhiyunzero byte. 56*4882a593Smuzhiyun 57*4882a593SmuzhiyunOnce the request is made via an `ioctl() <ioctl_>`_ passing a ``struct 58*4882a593Smuzhiyunbinder_device`` with the name to the kernel it will allocate a new binder 59*4882a593Smuzhiyundevice and return the major and minor number of the new device in the struct 60*4882a593Smuzhiyun(This is necessary because binderfs allocates a major device number 61*4882a593Smuzhiyundynamically.). After the `ioctl() <ioctl_>`_ returns there will be a new 62*4882a593Smuzhiyunbinder device located under /dev/binderfs with the chosen name. 63*4882a593Smuzhiyun 64*4882a593SmuzhiyunDeleting binder Devices 65*4882a593Smuzhiyun----------------------- 66*4882a593Smuzhiyun 67*4882a593Smuzhiyun.. _unlink: http://man7.org/linux/man-pages/man2/unlink.2.html 68*4882a593Smuzhiyun.. _rm: http://man7.org/linux/man-pages/man1/rm.1.html 69*4882a593Smuzhiyun 70*4882a593SmuzhiyunBinderfs binder devices can be deleted via `unlink() <unlink_>`_. This means 71*4882a593Smuzhiyunthat the `rm() <rm_>`_ tool can be used to delete them. Note that the 72*4882a593Smuzhiyun``binder-control`` device cannot be deleted since this would make the binderfs 73*4882a593Smuzhiyuninstance unuseable. The ``binder-control`` device will be deleted when the 74*4882a593Smuzhiyunbinderfs instance is unmounted and all references to it have been dropped. 75