Hello List,
Murphy is a resource policy manager used in Tizen IVI (see
https://01.org/murphy for more information). I wish to propose providing
Murphy as an alternative policy manager also in Tizen Mobile.
Disclaimer: I'm a Murphy developer.
INTRODUCTION
What is resource policy management? The idea is that there are limited
resources available in the system, such as the permission to play audio.
In systems that have limited user interaction capabilities (like IVI and
Mobile) the automatic handling of these resources is more important than
in traditional desktop systems. For example, when a call is coming in,
the ringtone player must get the audio playback permission even if there
was a media player application playing music. The media player
application must stop playing music, but in can continue playback when
the call is ended.
In IVI the policies are more complex than in Mobile: there can be
several simultaneous users and sessions, several entertainment units,
driving safety regulations, and cross-domain policies. The car data must
be taken in account when the policy decisions are made. For example,
when the car starts to move, the resource constraints change, and some
applications may lose the resources they already have.
At the moment there are two resource policy solutions in Tizen: Murphy
and Samsung-developed Audio Session Manager (ASM) used in Mobile
vertical. It makes little sense to have two policy managers in Tizen --
having only one would prevent fragmentation, make maintenance easier and
provide a better story for developers and system integrator. I think
that replacing ASM with Murphy in Mobile vertical in long term would be
a good idea.
COMPARISON OF THE POLICY MANAGERS
ASM consists of two parts: an application library (written in C) for
requesting resources and a system daemon managing the resources. The
communication between the library and daemon is done using System V
message queues and files. Murphy has a resource backend and a number of
different frontends for accessing it, including C library, D-Bus
bindings, and support for ASM library. So in effect, Murphy can be used
as a replacement for ASM without having to do any changes in the
existing applications.
Murphy has several benefits compared to ASM:
1. Murphy is configurable. Murphy uses Lua as configuration and policy
decision language. For performance-critical tasks the processing can be
lifted to plugins written in C. ASM has all policies hard-coded in the
binary itself. Configurability is important because it allows vendors to
prototype quickly and cheaply and customize the way the device should
behave without forking the policy manager component itself.
2. Murphy is a real open source project. Customers willing to improve
Murphy can write patches and send them to Murphy mailing list. Murphy
team also tries to keep documentation on the web pages up-to-date and
comprehensive.
3. Murphy resource APIs are more modern. The System V message queues ASM
uses don't provide file descriptors that the applications could add to
select/poll function arguments. Instead the request-response messaging
is done by blocking in the receive message call, meaning that the
application must either prepare for a delay or use concurrency. Murphy
APIs are asynchronous.
On the other hand, ASM is already used in Tizen Mobile and appears to
work well enough.
PERFORMANCE CONSIDERATIONS
I made a quick-and-rough performance comparison of the two policy
managers running on the same phone platform. Murphy was using the ASM
frontend to the resource library. Three test cases were performed:
simple resource request, resource request leading to preemption (another
application losing the request) and a failed resource request. The times
measured are from the arrival of the first ASM message to the response
message being sent out.
Top bar of every measurement pair represents Murphy (*) and bottom bar
represents ASM backend (=). Time is in milliseconds.
simple ********************************* 11.5
===================================== 12.4
preemption *************************************************** 17.0
======================================== 13.7
failed ********************************* 11.1
================= 5.4
time (ms) 0 5 10 15 20
The results show that the policy managers have more or less similar
performance. ASM clearly is faster in the test case where the resource
request fails (resource is not granted to the caller). However, with
some optimization, such as turning off logging, most likely both
resource managers couĺd be made to perform better.
PROPOSAL
I propose adding Murphy as an "alternative" resource manager to the
Tizen Mobile in 3.0 time frame. Any vendor wishing to experiment with
Murphy would be free to do so by configuring the system to use Murphy
instead of ASM. After Tizen 3.0, the maintainers of the Tizen Mobile
media stack could consider replacing ASM with Murphy.
All comments and questions are welcome!
--
Ismo Puustinen <[email protected]>
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
