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.136; helo=mga12.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 DB2AC21197B0E for ; Fri, 30 Nov 2018 08:48:23 -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 fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2018 08:48:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,299,1539673200"; d="scan'208";a="94677979" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga007.jf.intel.com with ESMTP; 30 Nov 2018 08:48:22 -0800 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.125]) by ORSMSX105.amr.corp.intel.com ([169.254.2.237]) with mapi id 14.03.0415.000; Fri, 30 Nov 2018 08:48:22 -0800 From: "Kinney, Michael D" To: "Carsey, Jaben" , "Ni, Ruiyu" , krishnaLee , "Kinney, Michael D" CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] [RFC] Proposal to add edk2-apps repository Thread-Index: AdSICyi1FOLm4mmqTpGbGl5+h6SFgAAbIBgAAAxvsND//8/egIAAIDMA//+6lAD//2Z2gA== Date: Fri, 30 Nov 2018 16:48:21 +0000 Message-ID: References: <20181129224102.ab43kwgrkk6xz2bl@bivouac.eciton.net> <129a947f.308c.167624a3bd2.Coremail.sssky307@163.com> <734D49CCEBEEF84792F5B80ED585239D5BF35F4B@SHSMSX104.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.138] 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 16:48:24 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One of the goals with this proposal is to minimize the amount of source code that needs to be setup in a WORKSPACE to build firmware for a given platform. If a platform does not require any applications that require the libc, then it would be better if the libc related packages and applications that use libc do not have to be present in WORKSPACE. Likewise, there are platforms that do not require the UEFI Shell or any other UEFI Applications in order to build the platform firmware image. Perhaps we need one repo for libc related content and another repo for UEFI Application related content. Best regards, Mike > -----Original Message----- > From: Carsey, Jaben > Sent: Friday, November 30, 2018 7:50 AM > To: Ni, Ruiyu ; krishnaLee > ; Kinney, Michael D > > Cc: edk2-devel@lists.01.org > Subject: RE: [edk2] [RFC] Proposal to add edk2-apps > repository >=20 > I do not think that expanding shellPkg would work since > there is no requirement that any of these apps depend > on it. As was stated, MicroPythonPkg does not. >=20 > I also do not think that moving ShellPkg makes lots of > sense since it is used by many platforms. >=20 > -Jaben >=20 > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel- > bounces@lists.01.org] On Behalf Of Ni, > > Ruiyu > > Sent: Thursday, November 29, 2018 7:40 PM > > To: krishnaLee ; Kinney, Michael D > > > > Cc: edk2-devel@lists.01.org > > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps > repository > > Importance: High > > > > Krishna, > > The reason there are applications inside > MdeModulePkg/Application is that > > the shell protocol was in ShellPkg when the app was > developed and > > MdeModulePkg cannot depend on ShellPkg (rule). > > Now since shell protocol is moved to MdePkg, any apps > can depend on shell > > protocol. (In fact they wanted to but just wasn't > allowed due to reason > > above.) > > > > I even prefer to move the ShellPkg to the edk2-app > repo Mike proposed. > > Instead 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 > > > > > > 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_application"; > > > 2,some apps have no dependency on uefi_shell(such > as apps in > > > MdeModulePkg/Application),I would call them > > "standard_uefi_application". > > > > > > The "AppPkg / StdLib / StdLibPrivateInternalFiles" > packages are usually > > used by > > > uefi_shell_application,I think they can all move to > ShellPkg,no need to > > create > > > new package ? > > > > > > > > > Thanks, > > > krishna. > > > > > > 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 > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel