Hi all, Let me clarify following situation.
As I understand, oprofile/valgrind git is for SDK (that’s only reason why they are in Tizen maintained git) (1) Valgrind: pre-packaged into SDK (valgrind is a default feature of Tizen SDK) - Installed into emulator/target image on-demand (first connection b/w IDE & emulator/target) (2) Oprofile: pre-loaded in mobile profile image to be used in the SDK (oprofile support is mandatory feature in Tizen compliance) - We are maintaining oprofile git because we want to make its footprint as small as possible for target. In summary, the reason why we (SDK domain) are having/maintaining upstream git in Tizen git is above purpose. If someone (mainly platform developers) want to use valgrind, oprofile for their own use case as following e-mail threads, I suggest NOT to use the version of Tizen git, But to use the version of origin upstream source of valgrind/oprofile. Of course, If there is another reason to embed another (additional) valgrind/oprofile into Tizen maintained git, you can do that under proper process (request/approval by architect group, assigning maintainer for that) Thanks, -- BR, Hyun-Goo Kang From: [email protected] [mailto:[email protected]] On Behalf Of 김주영 Sent: Thursday, November 21, 2013 2:31 PM To: Douglas, William Cc: [email protected] Subject: Re: [Dev] About oprofile and valgrind git Hi, Mr William We made the platform/upstream/oprofile git inside the sdk domain in approprate process. If you or someone architect don't like that path name or the domain, then you have to raise the issue and discuss about it. (If you want to do, please raise as the new issue with another mail.) What I am concerning is, someone who dosen't has any privilege in the sdk domain, played the maintainer role of the git in the sdk domain. And that has been happened without any notice to anyone in the sdk domain. I think the archtects of tizen have to take this situation seriously. One more general question of personnal curious. Basically I don't care which git is made in the platform domain. But I just don't understand why there are general copy of valgrind and oprofile gits are in the platform domain. Maybe if you need to upload the valgrind in the ivi, then just get it directly from valgrind open source. It seems to be that most of copy of linux open sources are inside the tizen git in the future. If there is any special reason for the valgrind and oprofile, I hope you or someone kindly explain about this. thank you. ------- Original Message ------- Sender : Douglas, William<[email protected]> Date : 2013-11-21 03:34 (GMT+09:00) Title : Re: [Dev] About oprofile and valgrind git Hello Mr Kim, On Wed, Nov 20, 2013 at 3:20 AM, 김주영 <[email protected]> wrote: In tizen 3.0, the 2 valgrind and 2 oprofile gits were added. I think we need to discuss to rearrange these gits for each valgrind and oprofile. 1. valgrind We have 2 gits for valgrind which are sdk/tools/upstream/valgrind and platform/upstream/valgrind. These 2 gits are basically used as same purpose. So we don't need to keep 2 gits. For the more, we don't have to preload the valgrind in the target image, no problem after installing the valgrind to the target, and the native IDE already have supported installing the valgrind automatically. If there are someones who want to make package and install it by themselves, they also can use the sdk/tools/upstream/valgrind git. And the valgrind is one of the tool of sdk, this path is reasonable. I don't understand why platform/upstream/valgrind is necessary. As valgrind isn't used for only development on the sdk it doesn't make sense to me to use the sdk's valgrind tool. Loading ivi or pc development images with the upstream valgrind has been a use case we've taken advantage of. 2. OProfile We have 2 gits which are sdk/tools/upstream/oprofile and platform/upstream/oprofile. Unlike the valgrind case, we need to keep 2 gits for oprofile. Because some of the oprofile need to be run by the root (i.e. oprofiled), the oprofiled and some related files need to be in the readonly area of the target for the security safety. But if we preload all the oprofile files in the target, it took too much space. So I made the platform/upstream/oprofile for packaging mini-oprofile which have only must-not-be-changed files. And the sdk/tools/upstream/oprofile is for packaging the other files, and this package also installed from native IDE automatically. Maybe there are someones who want to have full oprofile package. I would suggest 2 solutions. First, make the packaging script for platform/upstream/oprofile to produce 2 packages which are mini-oprofile and oprofile(oprofile-full). Second, make a new profile/mobile/platform/upstream/oprofile git for mini- oprofile package. I prefer first one. Same comment for valgrind applies to oprofile, these are generic development tools. 3. maintainer of valgrind and oprofile Regardless of above both issues, the valgrind and the oprofile are of the SDK tools. So these related gits must be interrited from scm/acls/domain_sdk. and must be maintain by SDK maintainer group. But I found the platform/upstream/valgrind was inherrited from scm/acls/domain_platform_development. And even though the platform/upstream/oprofile was inherrited from scm/acls/domain_sdk, Mr. Patrick McCarty have maintained this git. As far as I know, Mr. Patrick McCarty is not a member of any maintainer, intergrator or reviewer group of sdk domain. I think we need to fix this situation, and normally make the valgrind and oprofile git to be maintained by sdk maintainer group. Since the tools aren't exclusively sdk development tools, having the maintership in the sdk domain also doesn't make sense to me. Thanks, William <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=402a898772f97bc955a9d47 f3206432c1d1c185c1f2978220a25ab867575f4abbb20f3dfa9b426c1c7b738679db1e097a72 8c55b39cc59eacf878f9a26ce15a0>
<<image001.gif>>
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
