Shiva,
I created a FAQ reflecting our recent discussion, hoping this will help
the community.
See: https://wiki.tizen.org/wiki/Multi-user_Architecture#FAQ
Please find below the answers to your questions:
1) See
https://wiki.tizen.org/wiki/Multi-user_Architecture#Is_there_a_tizen_3.0_branch_in_platform.2Fcore.2Fappfw.2Ftizen-platform-config_.3F
Actually, I don't see much tizen_3.0 branches on repos. Do you have an
example of such project where tizen_3.0 branch is already created ?
2) The pkgs are available.
See:
https://wiki.tizen.org/wiki/Multi-user_Architecture#Is_tizen-platform-config_available_.3F
3) I tried to summarize the different use cases we encounter.
See:
https://wiki.tizen.org/wiki/Multi-user_Architecture#tizen-platform-config_usage
Using the tzplatform_xxx API is the good way to do things because it's
simple, efficient and will be a good control point for future enhancements.
Also note, that if you don't use the wrapper lib, you're on your own to
parse the config file and evaluate variables: in particular, you can't
count on the TZ_XXX variables to be present in the process environment
and getenv() won't work in any situation.
I push below the full FAQ for reference and web indexing.
Regards,
Stéphane
--
Stéphane Desneux
Intel OTC - Vannes/FR
--------------------------------------------------------------------------------
Source url: https://wiki.tizen.org/wiki/Multi-user_Architecture#FAQ
== FAQ ==
Initial version - 2013/12/19
=== Are the variables definitions finalized ? ===
No, the full list of variables defined in tizen-platform-config is not
finalized yet.
From day to day, we have to add new paths, depending on the packages we
fix. So, the variables that are already defined shouldn't be removed
(except if we find that we can merge 2 variables in one, i.e.
associating the same path for two resources).
Some new variables/paths will certainly be added, as we progess in the
list of the 200+ packages to fix.
If a developer needs to fix a given package, the corresponding variables
may be missing in tizen-platform-config.
In this case, the developer must add the new variable definition in
tizen-platform.meta (in platform/core/appfw/tizen-platform-config source
repo) then push for review on gerrit: we'll merge the addition.
=== Do the changes for multiuser apply to Tizen3.0 only ? ===
Yes it's only for Tizen 3.0.
=== Do we need any specific testing ? ===
Actually, the tizen-platform-config reflects the Tizen 2.1/2.2 single
user situation: the paths/uids/... defined in the variables are the same
as the ones we find in the source code or spec files.
So testing is not specific yet: we must just ensure that the fixes to
remove hardcoded items don't break things: after the fix, each package
must work as before.
Later, we'll have to add specific tests for multiuser modes (ex:
concurrency between users, sharing resources between users etc.)
=== Migration roadmap ===
We prepare the evolution in 4 steps:
* Step 1: we switch from hardcoded paths/uid/... to dynamicaly defined
paths/uid/... depending on the platform (profile), but the values
remains the same and we're still in single user mode = "Tizen 2.x
compatible"
* Step 2: we change user id and name (no more 'app' with uid=5000 but
for example 'user1' with uid=1234) => this will break some mechanisms.
After the fixes, we're still in single user mode, but flexible (user
name/uid can be changed)
* Step 3: switch the tizen-platform-config to "real" multi user mode:
paths are changed to reflect a real multiuser model. Again, this will
break things and fixes will be done.
* Step 4: finally, depending on each platform, we could have different
multiuser modes: simultaneous or exclusive. Again, some things will
break depending on the platform, concurrency/sharing modes etc.
=== Is there a tizen_3.0 branch in
platform/core/appfw/tizen-platform-config ? ===
No. This is not needed yet.
Usually, development on next release is done in 'tizen' then a branch is
created when releasing.
The purpose of tizen-platform-config is to give the paths, uids, groups
etc. for a given profile. So, we expect to have it forked inside each
profile (for ex. in profile/mobile/tizen-platform-config) to fit the
specifics of each vertical profile. But this fork will happen later,
when the hardcoded paths/uids will have been removed from the actual code.
=== Is tizen-platform-config available ? ===
Yes.
The binary packages generated from tizen-platform-config and
tizen-platform-wrapper are already present on Tizen:IVI and Tizen:Mobile
repos:
*
https://build.tizen.org/package/show?package=tizen-platform-config&project=Tizen%3AIVI
*
https://build.tizen.org/package/show?package=tizen-platform-config&project=Tizen%3AMobile
Any code in a tizen_3.0 branch should use the tizen-platform-config
definitions ('tizen' branch).
=== tizen-platform-config usage ===
We strongly encourage to use tizen-platform-config and its companion
packages, for simplicity and code uniformity.
There are multiple ways to use the evaluated variables:
* in source code: use libtzplatform-config RPM
*: This contains the wrapper library with its API calls: tzplatform_*().
*: The wrapper takes care of memory and concurrency aspects (it's
threadsafe).
*: It will make our life easier when migrating the 200+ packages:
generally, hardcoded strings can be replaced directly by a
tzplatform_xxx() call without extra code to alloc, free, handle
concurrency etc.
*: Another advantage: once the migration will be done, it will be easy
to grep the sources for TZ_XXXXX variables and know which packages are
using a given path/variable.
*: The wrapper library parses the /etc/tizen-platform.conf file on first
access to a TZ variable and evaluates all variables. This is done once
in a process life (or after each tzplatform_reset()) for efficiency and
results are stored in a perfect hash table generated by gperf for speed.
*: We also added some helping functions to fit the common uses we
encounter in source code (generate file paths based on variables, append
suffixes, get uid for a give user name stored in a variable ...)
* in spec files: use libtzplatform-config-devel RPM
*: A RPM macro file (/etc/rpm/macros.tizen-platform) contains the TZ_XXX
variables as rpm macros (ex: use %TZ_SYS_HOME in a spec file).
*: NB: of course, the user specific variables are not exported as we
can't deal with a non-existing user at build time.
* in bash scripts: use tizen-platform-config RPM
*: /etc/tizen-platform.conf is compatible with bash. Source it, use it.
* alternate helper: use tizen-platform-config-tools RPM
*: This package contains the tzplatform_get tool: this is a simple query
tool to get the variable values. The difference with direct sourcing of
the conf file is that it uses the wrapper lib and no bash mechanisms:
the values returned by tzplatform_get are guaranteed to be the same
within the source code through the wrapper lib.
--------------------------------------------------------------------------------
On 18/12/2013 13:01, SHIVAKUMAR JAGALUR MATT wrote:
Dear Stephane,
Thanks for the Information. We will review our Telephony package, if we
found any other hardcode variable, which is not found in tizen-platform-config,
we will add it to the file tizen-platform.meta
then push for review. I need few other information as below:
1) The code available in project platform/core/appfw/tizen-platform-config is under
"tizen" and some other branches only, but "tizen_3.0" branch is not listed yet
? So which branch code we should use ?
2) So, if we want to eliminate the hardcode paths found in our packages and fix them ( use
the new variables availale in tizen-platform-config in our module) , We need to wait till the file
tizen-platform-config or tizen-platform.meta is found on "tizen_3.0" branch, then we can
change in our module code, test the module and push our new modified code to gerrit? OR We need to
test is locally using tizen-platform-config available in "tizen" branch.
3) Do we need to use new variables availale in tizen-platform-config in
our module OR Do we need use platform wrapper apis availble in project
platform/core/appfw/tizen-platform-wrapper, i.e tzplatform_getname()
tzplatform_getui() and test our modules?.
Thanks
Shiva
------- Original Message -------
Sender : Stéphane Desneux<[email protected]>
Date : Dec 17, 2013 20:28 (GMT+09:00)
Title : Re: Regarding Multi-User architecture,
https://bugs.tizen.org/jira/browse/PTREL-285
Dear Shiva,
Please find my answers in your text. Added Dominique in copy.
On 17/12/2013 06:40, SHIVAKUMAR JAGALUR MATT wrote:
Dear Sunil and Stephane,
I am working for Tizen::Telephony framework component, i
need few information regarding Multi-User architecture changes.
1) Is the path that we need to change to suppourt multi-user
is finalized now, https://wiki.tizen.org/wiki/Multi-user_Platform_Metadata ?
Any hardcoded path, user name, uid/gid must be changed. They are
replaced by variables defined in tizen-platform-config (through
different mechanisms depending on where the hardcoded item is found)
Actually, the full list of variables defined in tizen-platform-config is
not finalized yet. From day to day, we have to add new paths, depending
on the packages we fix.
So, the variables that are already defined shouldn't be removed (except
if we find that we can merge 2 variables in one, i.e. associating the
same path for two resources). Some new variables/paths will certainly be
added, as we progess in the list of the 200+ packages to fix.
If you (your team) want to fix a given package, it may happen that you
don't find the corresponding variable in tizen-platform-config. In this
case, simply add it to the file tizen-platform.meta then push for review
on gerrit and we'll merge the addition.
2) Is these changes apply to Tizen3.0 only?. is the Tizen3.0
branch is ready to recevie submissions?
Yes it's only for Tizen 3.0.
3) Do we need any specific testing to ensure these changes
made to suppourt Multi-User architecture?.
tl;dr: Testing is not specific yet: we must just ensure that the fixes
for multiuser mode don't break things. Later, we'll have to add specific
tests for multiuser modes (ex: concurrency between users, sharing
resources between users etc.)
Long story:
Actually, the tizen-platform-config reflects the Tizen 2.1/2.2 single
user situation: the paths/uids/... defined in the variables are the same
as the ones we find in the source code or spec files.
We prepare the evolution in 4 steps:
Step 1: we switch from hardcoded paths/uid/... to dynamicaly defined
paths/uid/... depending on the platform (profile), but the definition
remains the same and we're still in single user mode = "Tizen 2.2
compatible"
Step 2: we change user id and name (no more 'app' with uid=5000 but
'user1' with uid=1234) => this will break some mechanisms. After the
fixes, we're still in single user mode, but flexible (user name/uid can
be changed)
Step 3: switch the tizen-platform-config to "real" multi user mode:
paths are changed to reflect a real multiuser model. Again, this will
break things and should be fixed.
Step 4: finally, depending on each platform, we could have different
multiuser modes: simultaneous or exclusive. Again, some things will
break depending on the platform, concurrency/sharing modes etc.
Actually, we're in step 1 and we must test that the packages that we fix
(remove hardcoded paths) are not broken. After the fix, they must work
as before: no specific test to add yet.
Thanks
Shiva
You're welcome. I hope this clarifies the roadmap.
Best regards,
Stéphane
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
