[Dev] Fwd: Fwd: Re: Regarding Multi-User architecture, https://bugs.tizen.org/jira/browse/PTREL-285

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Thu Dec 19 11:12:05 GMT 2013


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<stephane.desneux at open.eurogiciel.org>
>
> 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
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
>


More information about the Dev mailing list