From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.115; helo=mga14.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3DEE821180F27 for ; Thu, 29 Nov 2018 19:40:09 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2018 19:40:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,297,1539673200"; d="scan'208";a="94339992" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga007.jf.intel.com with ESMTP; 29 Nov 2018 19:40:08 -0800 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 29 Nov 2018 19:40:08 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX102.amr.corp.intel.com (10.18.124.200) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 29 Nov 2018 19:40:08 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.203]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.176]) with mapi id 14.03.0415.000; Fri, 30 Nov 2018 11:40:06 +0800 From: "Ni, Ruiyu" To: krishnaLee , "Kinney, Michael D" CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] [RFC] Proposal to add edk2-apps repository Thread-Index: AdSICyi1FOLm4mmqTpGbGl5+h6SFgP//zMgAgAAjLwCAABAsgP//W1Jw Date: Fri, 30 Nov 2018 03:40:06 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BF35F4B@SHSMSX104.ccr.corp.intel.com> References: <20181129224102.ab43kwgrkk6xz2bl@bivouac.eciton.net> <129a947f.308c.167624a3bd2.Coremail.sssky307@163.com> In-Reply-To: <129a947f.308c.167624a3bd2.Coremail.sssky307@163.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2EyMDE2ZmUtOTQ4Ni00ZTdlLWI2NGMtY2E1NTY4YmM3YTVhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieWNtRklsOXhcL0MxT2xtSnZyNVhxRkdXUFFQRmE1SmhwK3ZyemtRclwvNnNXSGViYjBRT3Bkbk90K1FwUXUxMkdMIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [RFC] Proposal to add edk2-apps repository X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 03:40:09 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Krishna, The reason there are applications inside MdeModulePkg/Application is that t= he shell protocol was in ShellPkg when the app was developed and MdeModuleP= kg cannot depend on ShellPkg (rule). Now since shell protocol is moved to MdePkg, any apps can depend on shell p= rotocol. (In fact they wanted to but just wasn't allowed due to reason abov= e.) I even prefer to move the ShellPkg to the edk2-app repo Mike proposed. Inst= ead of enlarge the ShellPkg:) I don't prefer edk2-libc unless we have a strategy/plan to make ordinary C = developer easy by promoting the std-c pkg. The other reason I prefer edk2-app is then ShellPkg might be moved to that = new repo. > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > krishnaLee > Sent: Friday, November 30, 2018 9:45 AM > To: edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository >=20 > Kinney, > I always think there may be two kinds of apps: > 1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,..= .they > usually execute under uefi_shell),I would call them "uefi_shell_applicati= on"; > 2,some apps have no dependency on uefi_shell(such as apps in > MdeModulePkg/Application),I would call them "standard_uefi_application". >=20 > The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually u= sed by > uefi_shell_application,I think they can all move to ShellPkg,no need to c= reate > new package ? >=20 >=20 > Thanks, > krishna. >=20 > At 2018-11-30 08:46:58, "Kinney, Michael D" > wrote: > >Leif, > > > >I did consider the edk2-libc name. The port of Python 2.7 is in the > >AppPkg as well and it uses libc. > > > >So the content of this new package is a combination of libc And apps > >that use libc. > > > >I am definitely open to alternate names. 2 options so far: > > > >* edk2-apps > >* edk2-libc > > > >Thanks, > > > >Mike > > > >> -----Original Message----- > >> From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > >> Sent: Thursday, November 29, 2018 2:41 PM > >> To: Kinney, Michael D > >> Cc: edk2-devel@lists.01.org > >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository > >> > >> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael D wrote: > >> > Hello, > >> > > >> > I would like to propose the creation of a new repository called > >> > edk2-apps. This repository would initially be used to host the > >> > following packages from the edk2 repository: > >> > > >> > * AppPkg > >> > * StdLib > >> > * StdLibPrivateInternalFiles > >> > >> Let me start by saying I 100% back moving these out of the main edk2 > >> repository. > >> > >> > These 3 packages provide support for the libc along with > >> > applications that depend on libc. None of the other packages in > >> > the edk2 repository use these packages, so these 3 package can be > >> > safely moved without any impacts to platform firmware builds. > >> > Build configurations that do use libc features can clone the > >> > edk2-apps repository and add it to PACKAGES_PATH. > >> > >> I must confess to never having properly understood the scope of > >> AppPkg to begin with. > >> > >> AppPkg/Applications/Hello does not appear to have any further (real) > >> dependency on libc than MdeModulePkg/Application/HelloWorld/, and . > >> > >> And certainly MdeModulePkg/Applications contain plenty of ... > >> applications. > >> > >> So, if the purpose is simply to provide some examples of application > >> written to libc rather than UEFI - should this be edk2- libc instead? > >> > >> Best Regards, > >> > >> Leif > >> > >> > The history of these 3 packages would be preserved when importing > >> > the content into edk2-apps. After The import is verified, these 3 > >> > packages would be deleted from the edk2 repository. > >> > > >> > This proposal helps reduce the size of the edk2 repository and > >> > focuses edk2 repository on packages used to provide UEFI/PI > >> > conformant firmware. > >> > > >> > If there are no concerns with this proposal, I will enter a > >> > Tianocore BZs for the two steps. > >> > > >> > Best regards, > >> > > >> > Mike > >> > _______________________________________________ > >> > edk2-devel mailing list > >> > edk2-devel@lists.01.org > >> > https://lists.01.org/mailman/listinfo/edk2-devel > >_______________________________________________ > >edk2-devel mailing list > >edk2-devel@lists.01.org > >https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel