I've made a little mistake after checking xwalk.service is added to default.taget and linked to preinstall widget service (by Before instruction).
This leads to launch at boot time. Removing this symbolic link and reference in should be done and doesn't break the dbus launch on demand. My proposal is to remove scripts/generic-crosswalk.post from meta-generic package. There is no need to keep this. Preinstallation doesn't requires the xwalk deamon. 2014-11-04 15:40 GMT+01:00 Baptiste Durand < [email protected]>: > > > 2014-11-04 12:40 GMT+01:00 Rafał Krypa <[email protected]>: > >> On 2014-11-04 11:49, Dominig ar Foll (Intel OTC) wrote: >> > Le 04/11/2014 11:02, Rafał Krypa a écrit : >> >> On 2014-11-04 09:25, Zhang, Xu U wrote: >> >>> Hi Rafal, >> >>> >> >>> I have forwarded your email to Crosswalk mail list. Misha , who is >> key contributor for Crosswalk reply here: >> >>> >> https://lists.crosswalk-project.org/pipermail/crosswalk-dev/2014-October/002165.html >> >>> >> >>> I have a question on setting SMACK label for gpu process. GPU process >> is shared by all render process in the same user just as browser process. >> What SMACK label should be set for GPU process? What API should we call? >> >> Hi Xu, >> >> Let me summarize the whole picture including the GPU process and the >> Zygote process and how I think they security configuration should be >> handled: >> >> >> >> *Browser process* >> >> Will be launched by "systemd --user". Runs with label "User" and with >> privilege (capabilities for setting Smack labels). You don't have to call >> anything to change it's security settings, with one exception (described >> below at Zygote process). >> > We need to NOT start the browser process immediately at user login >> because Crosswalk launch is heavy and will take time and resources. We >> should start Crosswalk when needed by launching it via the native launching >> on demand. >> >> How about using existing mechanism for on demand launching? When a >> Crosswalk application is started, extension process tries to connect to the >> browser process. We could configure browser process to be started on demand >> in that moment. My first bet was systemd socket activation, but >> communication >> between EP and BP is over dbus. I'm not a dbus expert, but I think that >> dbus could also perform on-demand starting of the browser process. >> > > There is some confusion here. > > Dbus doesn't launch crosswalk it delegates it to systemd > > > cat /usr/share/dbus-1/services/org.crosswalkproject.Runtime1.service > [D-BUS Service] > Name=org.crosswalkproject.Runtime1 > SystemdService=xwalk.service > Exec=/bin/false > > Dbus uses systemd service to launch xwalk on demand. > > Please remember that xwalk.service is not associated to a "systemd" target > so crosswalk is never launch at boot time > > It is only done through DBUS request. > > There is no problem here. > > > _______________________________________________ >> Dev mailing list >> [email protected] >> https://lists.tizen.org/listinfo/dev >> > > > > -- > Baptiste DURAND > Eurogiciel Vannes/FR > -- Baptiste DURAND Eurogiciel Vannes/FR
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
