Lưu ý
Mục đích của file này là để độc giả tiếng Việt có thể đọc và hiểu tài liệu nhân kernel dễ dàng hơn, không phải để tạo ra một nhánh tài liệu riêng. Nếu bạn có bất kỳ nhận xét hoặc cập nhật nào cho file này, vui lòng thử cập nhật file tiếng Anh gốc trước. Nếu bạn thấy có sự khác biệt giữa bản dịch và bản gốc, hoặc có vấn đề về bản dịch, vui lòng gửi góp ý hoặc patch cho người dịch của file này, hoặc nhờ người bảo trì và người review tài liệu tiếng Việt giúp đỡ.
- Bản gốc:
- Người dịch:
Google Translate (machine translation)
- Phiên bản gốc:
8541d8f725c6
Cảnh báo
Tài liệu này được dịch tự động bằng máy và chưa được review bởi người dịch. Nội dung có thể không chính xác hoặc khó hiểu ở một số chỗ. Khi có sự khác biệt với bản gốc, bản gốc luôn là chuẩn. Bản dịch chất lượng cao (được review) được đặt trong thư mục vi_VN/.
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=<count>mount option serves as a per-instance limit. Ifmax=<count>is set then only<count>number of binder devices can be allocated in this binderfs instance.- stats
Using
stats=globalenables global binder statistics.stats=globalis only available for a binderfs instance mounted in the initial user namespace. An attempt to use the option to mount a binderfs instance in another user namespace will return a permission error.
Allocating binder Devices¶
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¶
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 unusable. The binder-control device will be deleted when the
binderfs instance is unmounted and all references to it have been dropped.
Binder features¶
Assuming an instance of binderfs has been mounted at /dev/binderfs, the
features supported by the binder driver can be located under
/dev/binderfs/features/. The presence of individual files can be tested
to determine whether a particular feature is supported by the driver.
Example:
cat /dev/binderfs/features/oneway_spam_detection
1