[Dev] Tizen 3.0 proposal for applications launch

Rusty Lynch rusty.lynch at intel.com
Thu Oct 10 17:25:28 GMT 2013

On Thu, 2013-10-10 at 17:06 +0000, Schaufler, Casey wrote:
> > -----Original Message-----
> > From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On
> > Behalf Of Jussi Laako
> > Sent: Thursday, October 10, 2013 9:22 AM
> > To: dev at lists.tizen.org
> > Subject: Re: [Dev] Tizen 3.0 proposal for applications launch
> > 
> > On 10.10.2013 19:03, Schaufler, Casey wrote:
> > > You can't. The whole notion of using a daemon in this way is a non-starter.
> >  > Your premise on how to accomplish your goal is flawed. It won't work.
> > Your plan
> >  > might be convenient if it was based on a system that worked the way
> > you're asking  > it to, but it does not.
> > >
> > > You need a different approach to launching applications.
> >  > Hammering on the design you've proposed is not going to result in a
> > functional system.
> > 
> > For starters I would like to understand why this launcher thingie needs to run
> > as root in first place? Why not just a normal session bus service without need
> > to worry about getting uids or gids right?
> Good question.
> One of our requirements is for application isolation.
> Somewhere along the line we quit assigning responsibility
> to people using applications and started assigning it to
> the application itself. We now want to ensure that
> applications don't interfere with each other, regardless
> of how the user might want to use them.
> To accomplish application isolation you need to invoke
> a security mechanism of some kind. Android uses UIDs.
> Tizen uses Smack labels. In any case, you're going to have
> to set a security attribute. That is going to require privilege.
> We have kernel based mechanisms (e.g. setuid bit,
> SMACK64EXEC attribute, SELinux context) to provide
> setting security attributes for application binaries.
> Unfortunately, there is a perception that the exec()
> processing is too slow (I have yet to see numbers to
> back this up, but "everyone knows" this is the case)
> so it is standard practice to implement application
> launchers to speed the process up. The application
> launcher has to do everything that the exec() call
> does. That includes setting security attributes.
> As noted above, this requires privilege.
> The easy and, to my mind correct, solution is to let the
> kernel take care of setting the security attributes and
> throw out the whole "launcher" thing. I have *never*
> been presented evidence that launchers actually
> improve performance in the final deployed configuration.
> But, that's a separate argument.

I don't know if we are missing some critical capability in Tizen 3.0,
but for the code that is currently in Tizen 3.0 built for IVI, it is
actually slower to launch an app via the prelauncher.  I am very curious
to know if this is also true for mobile images.

I haven't debugged this.  It could be something as simple as the
prelauncher attempting to read a vconf key that is not set (which
results in a series of 100ms retries for some reason i can't fathom).

But... in past projects i have been able to attain faster app startup
times with a prelaunch type model, but i wasn't trying to do fancy smack
stuff... just enabling the app to start from a state where basically
everything was loaded in memory ready to go.


More information about the Dev mailing list