Modern Operating Systems by Herbert Bos ...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Showing 851-852 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 851
820
CASE STUDY 1: UNIX, LINUX, AND ANDROID
CHAP. 10
Process 1
Process 1
Process 2
Object1b
Object2a
Object2a
Object1b
Handle 2
Handle 2
Handle 1
Handle 2
Handle 3
Handle 3
Handle 1
1
3
4
6
5
6
8
Transaction
Transaction
Transaction
Transaction
To: Handle 2
To: Handle 2
To: Object2a
From: Process 1
From: Process 1
To: Object2a
From: Process 1
Data
Data
Object1b
Data
Data
Data
Data
Object1b
Handle 3
Data
Data
Handle 3
Process 2
Kernel
7
2
Figure 10-45.
Transferring
Binder
objects between processes.
4. The kernel uses the target of the transaction,
Handle 2
, to determine
that this is intended for
Object2a
which is in
Process 2
.
5. The kernel now rewrites the transaction header to be appropriate for
Process 2
, changing its target to address
Object2a
.
6. The kernel likewise rewrites the transaction data for the target proc-
ess; here it finds that
Object1b
is not yet known by
Process 2
, so a
new
Handle 3
is created for it.
7.
The rewritten transaction is delivered to
Process 2
for execution.
8. Upon receiving the transaction, the process discovers there is a new
Handle 3
and adds this to its table of available handles.
If an object within a transaction is already known to the receiving process, the
flow is similar, except that now the kernel only needs to rewrite the transaction so
that it contains the previously assigned handle or the receiving process’s local ob-
ject pointer.
This means that sending the same object to a process multiple times
will always result in the same identity, unlike Linux file descriptors where opening
the same file multiple times will allocate a different descriptor each time.
The
Binder
IPC system maintains unique object identities as those objects move be-
tween processes.
The
Binder
architecture essentially introduces a capability-based security
model to Linux.
Each
Binder
object is a capability.
Sending an object to another
process grants that capability to the process.
The receiving process may then make
use of whatever features the object provides. A process can send an object out to
another process, later receive an object from any process, and identify whether that
received object is exactly the same object it originally sent out.


Page 852
SEC. 10.8
ANDROID
821
Binder User-Space API
Most user-space code does not directly interact with the
Binder
kernel module.
Instead, there is a user-space object-oriented library that provides a simpler API.
The first level of these user-space APIs maps fairly directly to the kernel concepts
we have covered so far, in the form of three classes:
1.
IBinder
is an abstract interface for a
Binder
object. Its key method is
transact
, which submits a transaction to the object.
The imple-
mentation receiving the transaction may be an object either in the
local process or in another process; if it is in another process, this will
be delivered to it through the
Binder
kernel module as previously dis-
cussed.
2.
Binder
is a concrete
Binder
object. Implementing a
Binder
subclass
gives you a class that can be called by other processes.
Its key meth-
od is
onTransact
, which receives a transaction that was sent to it.
The
main responsibility of a
Binder
subclass is to look at the transaction
data it receives here and perform the appropriate operation.
3.
Parcel
is a container for reading and writing data that is in a
Binder
transaction. It has methods for reading and writing typed data—inte-
gers, strings, arrays—but most importantly it can read and write refer-
ences to any
IBinder
object, using the appropriate data structure for
the kernel to understand and transport that reference across processes.
Figure 10-46 depicts how these classes work together, modifying Fig. 10-44
that we previously looked at with the user-space classes that are used.
Here we see
that
Binder1b
and
Binder2a
are instances of concrete
Binder
subclasses. To per-
form an IPC, a process now creates a
Parcel
containing the desired data, and sends
it through another class we have not yet seen,
BinderProxy
.
This class is created
whenever a new handle appears in a process, thus providing an implementation of
IBinder
whose
transact
method creates the appropriate transaction for the call and
submits it to the kernel.
The kernel transaction structure we had previously looked at is thus split apart
in the user-space APIs: the target is represented by a
BinderProxy
and its data is
held in a
Parcel
.
The transaction flows through the kernel as we previously saw
and, upon appearing in user space in the receiving process, its target is used to de-
termine the appropriate receiving
Binder
object while a
Parcel
is constructed from
its data and delivered to that object’s
onTransact
method.
These three classes now make it fairly easy to write IPC code:
1. Subclass from
Binder
.
2. Implement
onTransact
to decode and execute incoming calls.
3. Implement corresponding code to create a
Parcel
that can be passed
to that object’s
transact
method.


Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades

Students also viewed documents