Young,
please find extra comment in line in the text.
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
Le 14/10/2013 14:34, YOUNG IK CHO a écrit :
I did not consider the
environment variable seriously so far. Currently, $HOME and
$DISPLAY is inherited from launchpad process but it should be
set properly on the multi-user environment. Launchpad invokes
_set_env() function to set its internal environment variable
but it sets only PKG_NAME so far. However, some module should
provide additional information like $HOME or $DISPLAY to to be
set. Myabe the directory policy should be deternined also:
where is $HOME directory for each user?
In a single user model, lauchpad, has the ENV information because
all the system was hard-wired. In a multi user model, we have ENV
variable that will differ from user to user and might not even be
fixed. Prime candidates are Display and D-BUS related variable.
All the challenge is to fine a simple but reliable method to obtain
the ENV if the user session and pass them over to the lauchpad via
amd.
This is to keep compatibility with current behavior. However,
Either or both of the following should be done to solve this
issue:
- Some platform daemon should run in the user-session.
- Some system-session daemon should use an explicit API to
specify the user id.
Challenge is to pass the access token (what ever they are) from the
deamon runing in the user-session to the launch daemon.
No, for my prototyping, all user process shares $HOME=/root
environment variable. Currently most of systemd-related API uses
system session instead of user session and simple launch test
does not detect DBUS-related use case.
Nice to see that we still get some serious issues to play with.
Do you have an idea to pass that ENV. We had quite active chat on
the mailing list on the issue but convergence is slow. Thanks to
shot your vision of a solution in the discussion.
Right, current platform db or vconf should be located on the
proper location.
It's not only location. We also need to deal with access conflicts
and the obvious over use of DB access during launching.
Well, the code itself does not seems to be that different but
the wrt-launchpad has additional platform initialization and
process-pool utilization. To avoid the code duplication, it is
desirable to make shared library to be shared for lanchpads.
That might be a nice compromise between full redesign and code
duplication.
Dominig
|
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
