[Dev] Multi User: Unique AMD with multiple Launchpads
stephane.desneux at eurogiciel.fr
Sat Oct 19 23:02:33 GMT 2013
Dominig ar Foll (Intel OTC) wrote:
>> Actually managing app lifecycle is the role of AMD. AMD is actually the
>> central daemon who maps process (pid) and app (appId).
> It seems that we are in sync, but we need to get the same wording.
> Yes, AMD is the central point and control the launch of an App for a given user.
> But the actual launch is done by one of the Launchpad(s) and so it's an easy
> point to keep track of the application which have been launched in order to
> control its live cycle.
> We could report all the live cycle control work to AMD, but that would require
> to pass back to AMD at least the pid once that the application has been launched.
> For me, its more a detail of implementation rather than an real architecture
> issue as I see the Launchpad(s) as an extension of AMD.
Actually, launchpads are technically the parent processes of the launched apps
and don't seem to have strong links with AMD (they are just slaves).
The primary reason to have launchpads is performance (not security, control or
anything else). So, from an architectural point of view, the launchpads could be
ignored. You could just see them as extensions of AMD.
So we should think about the architecture without being focused on launchpads.
IMO, having separate launchpads as actually is more a constraint than a benefit:
handling the application lifecycle is complex because it's distributed: in a
multiuser environment, we'd have a single launchpad which would be the parent of
applications launched by different users... As a user would probably launch
every kind of application (WRT/OSP/Core), we'll have multiple launchpads
involved. Where's the intelligence ? IMO, a launchpad must be dumb and just has
to run the things quickly. Its role is not to handle the whole lifecycle of
applications launched by multiple users: it's AMD's role.
Just an idea to go further, Would it be possible to have the actual launchpads
implemented as "plugins" of AMD (i.e running *inside* AMD). That would solve
- AMD would be the parent process of every launched app: a single lifecycle
could be controlled from AMD, whether the app is a WRT, OSP or core app.
- if there's some communication between launchpads and AMD, being inside AMD
makes probably thing easier (have a plugin API instead of a more or less complex
Intel OTC - Vannes/FR
More information about the Dev