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
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
