All, This is reminder request to provide input to Ismo for this feature.
Ismo, Please enter this feature request in JIRA for approval as an alternative feature for Tizen 3.0 Mobile. Thanks Sunil -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Puustinen, Ismo Sent: Friday, November 29, 2013 2:46 AM To: [email protected] Subject: [Dev] RFC: Use Murphy as policy manager for Tizen Mobile 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
