harmonizing policy management with murphy in genivi, agl ... · •solution in the poc ‒for...
TRANSCRIPT
Harmonizing policy management
with Murphy
in GENIVI, AGL and TIZEN IVI1
Long term TIZEN Objectives for harmonization
2
• Support in TIZEN for coexistence of GENIVI applications
• Allow portable business rules
• Harmonize HW adaptation
Murphy introduction
3
What is Murphy?
4
• Policy Management framework
• Open source projecthttp://01.org/murphy
• Liberal licensing
• The policy management framework in TIZEN IVIhttp://review.tizen.org/gerrit - sourceshttp://download.tizen.org - packages
What does the `policy management framework´ mean?
5
• Toolkit to build policy engines‒ Support libraries to make easy to
• write plugins• manage data (ie. Murphy provides a memory resident database)• communicate (over D-Bus, web socket, or export/import DB tables)• build logic networks
‒ LUA scripting• Can be used achieve portability
• Set of readily available frameworks that‒ Can be used without change‒ Can be modified/extended to fulfill special needs
• by scripting• by forking, ie. modifying/extending the existing plugins
‒ Can serve as an example how to write something new/different
What are the `readily available frameworks´ in Murphy?
6
• Audio management‒ Playback right management
‒ Routing
‒ Volume control
• Screen management‒ Layout management
‒ Visibility management
‒ Input management
• System resource management‒ Tracking
‒ Limit setting
Policy Model
7
Centralized decision• in Murphy daemon
• decision support data collected from
• system daemons
• policy aware applications
• domain servers
Distributed enforcement• in various domain controllers
• domain controllers are either
• plugins in a domain server
• plugins in murphy daemon
MurphyDomain
Controllers
Applicationspolicy unaware
DomainServers
Murphydaemon
SystemDaemons
Applicationspolicy aware
Architecture and operation
8
Murphydaemon
1. system state change
2. data collection
3. trigger decisions
4. store decisions
5. export decisions
6. enforce decisions
MurphyDB
Data Source
Domaincontroller
Decision Logic
2 5 61
3 4
Logic can span over multiple components
9
• DB tables can be exported/imported‒ single writer; multiple consumers
• DB exports‒ implemented by domain controller using domain control support library‒ exporting is triggered by database changes
• DB imports‒ domain controller can create/update DB tables in Murphy daemon
Murphy daemon Domain Controller
Domain Controller
Plugin
Domain Controller
LibraryLogicLogic
Multi host support
10
domaincontrollers
domaincontrollers
Centralised Distributed
SingleMurphy daemon
MasterMurphy daemon
SlaveMurphy daemon
domaincontrollers
domaincontrollers
host #1
host #2 host #2
host #1
Network Network
Audio Management
Harmonization of TIZEN and GENIVI audio stacks
11
PoC for harmonization of TIZEN - GENIVI
12
• Intel & ADIT currently make a joint effort to harmonize GENIVI & TIZEN audio stacks
• The resulting components will be open sourced
• The results will be part of future releases of Tizen
• the PoC will be the basis for GENIVI audio support in TIZEN
• GENIVI might consider to include also the resulting components and Murphy
Motivation for building the PoC
13
• Co-existence of TIZEN and GENIVI Audio applications
‒ Audio management in TIZEN and GENIVI are different
‒ Murphy and the GENIVI Audio Manager should be integrated
• Exploring how Murphy can be used
‒ See and learn the lessons how actual IVI audio use cases and environment can be implemented
‒ Make adjustments if needed
‒ Hope this attempt will be the starting point for policy management in IVI
Overview of GENIVI audio management
14
• Central management point inGENIVI Audio Manager
• Support for multiple domains
• “Brain” of audio policy is implemented in the Control Plugin
• Hardware adaptation is in the Router Plugins
• Applications are expected to request routes (connections) before playing back or capturing
Example for GENIVI audio management
15
routing / volume
GENIVI application
Linux Audio Server (ALSA)
Co
ntr
ol
Plu
g-in
Routing Plug-inFor ALSA
Routing Plug-inFor DSP
Command InterfacePlugin
GENIVI Audio Manager
GENIVI application
DSP
• Central management point inGENIVI Audio Manager
• Support for multiple domains
• “Brain” of audio policy is implemented in the Control Plugin
• Hardware adaptation is in the Router Plugins
• Applications are expected to request routes (connections) before playing back or capturing
Overview of audio management in TIZEN IVI
16
• Central management point in Murphy
• Enforcement point in the Sound Server
• Supports a single domain only
• Support for both policy aware and policy unaware applications
BlueZ
module-murphy-ivi plugin PulseAudio
ASMresource
pluginMurphy
ALSA
WRT application(policy aware)
Linux application(policy unaware)
Harmonization challenge: explicit vs. Implicit routing
17
• explicit routes
‒ GENIVI model
‒ applications explicitly set the routing targets
‒ an audio source can have 0+ explicit routes
‒ explicit routes are static, e.g. connecting new headsets will not effect existing explicit routes
• implicit routes
‒ WebRuntime and Linux applications
‒ automatic @ stream creation
‒ default routes determined by the stream class which in turn determined by a stream property and/or the name of the exe image
‒ an audio source can have 0 or 1 default route
• default routes are dynamic, eg. connecting a new headset might change the routing
Harmonization challenge: static vs. dynamic sinks/source
18
• Many Tier1 prefer static setups
‒ GENIVI Audio Manager supports both dynamic and static setups
‒ Pulseaudio (what is used in Tizen) supports just dynamic setups
• Solution in the PoC
‒ For GENIVI
• simulated static setup
• sink/sources appear all the time
• for sinks/sources that are implemented by applications availability changes as the application runs/exitse.g. a source implemented by an MP3 player become available when the player app runs and become unavailable when the app exits
‒ For TIZEN
• The usual dynamic setup
Harmonization challenge: routing logic
19
• GENIVI
‒ If an application wants to play
• It has to request a route (connection)
• Application should be aware of its own sink/source andthe routing target (the other end of the connection)
• TIZEN
‒ If an application wants to play it has to either
• create the stream and start to play (policy unaware apps)
• ask for playback rights beside creating a stream (policy aware)
‒ In both cases the policy engine determines the routing target ie. the source or sink
• The logic to determine the routing target is in a PulseAudio plugin (pulseaudio-module-murphy-ivi)
• In order to support multiple audio domains the logic had to be moved from PulseAudio to Murphy
How will the GENIVI Audio Manager will be supported in TIZEN
20
BlueZ
DSP
module-murphy-ivi plugin PulseAudio
GA
Msu
pp
ort
p
lugi
n
esourceplugin
Murphy
ALSA
GENIVI application
WRT application
Linux application
Routing volume
Implicit routing
logic
Mu
rph
yco
ntr
ol
plu
gin
D-BusRouter Interface
Plugin
DSPRouter Interface
Plugin
Command Interface
Plugin
Genivi Audio Manager
PoC components
Example flow
21
D-BusRouter Interface
Plugin
DSPRouter Interface
Plugin
Command InterfacePlugin
Genivi Audio Manager
BlueZ
DSP
module-murphy-ivi plugin PulseAudio
GA
Msu
pp
ort
p
lugi
n
resourceplugin
Murphy
ALSA
GENIVI application
WRT application
Linux application
Routing volume
Implicit routing
logic
Mu
rph
yco
ntr
ol
plu
gin
PoC test setup
22
mp3
Gat
way
1
Gat
way
2
Gat
way
3
DSP Domain
PulseAudio Domain
Radio GENIVI application
WRTapplication
ICOapplication
Gat
way
4
NavigationGENIVI application
ALSA Domain
Gat
way
5
Gat
way
6
Harmonized HW adaptation
23
• If you need to adapt new audio HW like DSP or external AVB amplifier ...
• Write a Router Plugin for GENIVI Audio Manager and you can use your HW in
‒ TIZEN for both• TIZEN apps (assuming your HW has ALSA PCM devices)
• GENIVI apps
‒ GENIVI platforms
Screen Management
24
Overview of Screen Management in TIZEN IVI
25
Weston Backends (drm, X11, ...)
Weston Core
ivi-shell
plugin
libivi-layout.so
ivi-controller.so hmi-controller.so
GENIVI application
Libilm_client.so
ivi-application protocols
Murphy
ivi-controller protocol
HomeScreen
libwayland-client.so
Wayland & Weston protocols
libwayland-server.so
TIZEN application
Screen Management main building blocks
26
• Regulator‒ Logic to adapt vehicle state, driver activities and application usage scenarios‒ Set of rules and/or state machines‒ Determines what applications can be active
• Layout Manager‒ Manages Areas and Layers‒ Assigns and moves surfaces to areas/layers‒ Depends on Regulations
• Resource Manager‒ Decides what active applications can do and when‒ Depends on Regulations
• Application Launcher / Task Switcher‒ Launches/kills application‒ Requests to switch active application
• Screen Controller‒ Carries out / enforces the decisions of Layout & Resource Manager
• Input Controller‒ Carries out / enforces the decisions of Input & Resource Manager
Screen Management in TIZEN M14.3 release
27
WestonMurphyHome Screen
LayoutManager
LayoutManager
LauncherTask Switcher
ResourceManager
Regulator
ScreenController
InputManager
InputManager
InputController
Implemented in ivi-shell & ivi-contoller
Screen Management PoC after TIZEN M14.3 release
28
WestonMurphyHome Screen
LayoutManager
LayoutManager
LauncherTask Switcher
ResourceManager
Regulator
ScreenController
InputManager
InputManager
InputController
LayoutManager
InputManager
Harmonized HW adaptation
29
• If you need to adapt new graphics HW ...
• Write a backend for Weston and you can use your HW in
‒ TIZEN for both• TIZEN apps (assuming your HW has ALSA PCM devices)
• GENIVI apps
‒ GENIVI platforms
Lifecycle ManagementHarmonization of TIZEN and GENIVI system resource management
30
System resource management in TIZEN
31
• Murphy can track‒ Memory usage (MemFree, SwapFree, Dirty, Writeback)‒ CPU load (Combined single virtual CPU, Per physical CPU, Per Cgroup)
• Murphy can notify‒ For notifications CPU and Memory watches can be defined
• The whole tracked value range is split into zones• Callbacks are set for each watch
‒ If a watched value goes from a zone to another the specified callback is called
• Murphy can setPer Cgroup
• Memory (limit_in_bytes, soft_limit_in_bytes, memsw.limit_in_bytes, swappiness)• CPU (shares, cfs_period_us, cfs_quota_us, rt_period_us, rt_runtime_us)• Freezer (state)
• Scriptable logic
Harmonization efforts
32
• Ongoing discussion with GENIVI folks
• Possible scenarios
‒ No harmonization at all
‒ Provide in TIZEN some of the GENIVI lifecycle management API’s using MurphyFirst target is the GENIVI Resource Management which is the counterpart of TIZEN system Resource Management
‒ The Murphy implementation could be used also in GENIVI
Future works in TIZEN
33
• Support for new Cgroup controllers
‒ net_cls (network bandwidth control)
‒ blkio (storage I/O bandwidth control)
• Application tracking
‒ Note: applications and processes are not necessarily the same• Web Runtime
• Threads, forks execs understood and handled properly
‒ Watches for applications• Similar mechanism what Murphy already has to track CPU and Memory usage
• Improvements to the existing features
‒ per Cgroup memory monitoring
Summary
34
Summary
35
• Harmonization areas‒ Audio Management
‒ Screen Management
‒ System Resource Management
• Achievement of objectives‒ Support in TIZEN for coexistence of GENIVI applications
• Audio Management: integration of Murphy and GENIVI Audio Manager
• Screen Management: use of Weston + IVI shell + Wayland IVI extension + integration of Murphy to Weston
‒ Allow portable business rules• Murphy’s configurability and scriptability
‒ Harmonize HW adaptation• Audio Management: GENIVI Audio Manager + Router Plugin
• Screen Management: Weston + backend