From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (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 119D020945B78 for ; Fri, 15 Sep 2017 16:55:34 -0700 (PDT) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 15 Sep 2017 16:58:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,399,1500966000"; d="scan'208,217";a="151920683" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga005.fm.intel.com with ESMTP; 15 Sep 2017 16:58:34 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 15 Sep 2017 16:58:34 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 15 Sep 2017 16:58:33 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.175]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.159]) with mapi id 14.03.0319.002; Sat, 16 Sep 2017 07:58:31 +0800 From: "Yao, Jiewen" To: "Yao, Jiewen" , Laszlo Ersek , "Ni, Ruiyu" , Paulo Alcantara CC: "Wu, Hao A" , "edk2-devel@lists.01.org" , "Zeng, Star" Thread-Topic: [edk2] Functionality issues in UDF support Thread-Index: AQHTLfGsbqtLEEo+YUKCCcB2+Y9nrKK1BMMAgAAEkYCAAImeAIAACiAAgAADf4CAAAMqAIAA9xzggAADueA= Date: Fri, 15 Sep 2017 23:58:31 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503A9BC3E0@shsmsx102.ccr.corp.intel.com> References: <734D49CCEBEEF84792F5B80ED585239D5BA4206B@SHSMSX151.ccr.corp.intel.com> <081B7D33-9F33-40CE-B569-62CC8C204B56@zytor.com> <734D49CCEBEEF84792F5B80ED585239D5BA420DF@SHSMSX151.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BA4212E@SHSMSX151.ccr.corp.intel.com> <1C01A5C1-09DE-4747-BA65-4EB668D76094@zytor.com> <734D49CCEBEEF84792F5B80ED585239D5BA42270@SHSMSX151.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BA42713@SHSMSX151.ccr.corp.intel.com> <508e1df7-fe00-126b-d583-c81db8514e10@redhat.com> <11481899-6F36-4877-B4FF-732B2781F3CB@intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A9BC398@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A9BC398@shsmsx102.ccr.corp.intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: Functionality issues in UDF support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 23:55:34 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Laszlo/Ruiyu/Star I went through the whole conversation and have some thought: For staging, I quote the description from https://github.com/tianocore/edk2= -staging I think UDF matches all below criteria. "edk2 required quality criteria" is= the key. We have lots of features there - such as StandaloneSmm, CustomizedSecureBoo= t, RiscV, ResetSystem, StructurePcd. All those features need more validation. We are following the rule and I think UDF feature can follow the same rule. If there is quality concern and the quality concern cannot be resolved in a= short period of time, the staging tree is a better choice. (NOTE: "Fix it immediately" is not an alternative; we can't do that.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D This repository is used by EDK II as a staging location for new features that are not yet ready for inclusion in EDK II. Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Need place on tianocore.org where new features that are not ready for produ= ct integration can be checked in for evaluation by the EDK II community prior = to adding to the edk2 trunk. This serves several purposes: * Encourage source code to be shared earlier in the development process * Allow source code to be shared that does not yet meet all edk2 required q= uality criteria * Allow source code to be shared so the EDK II community can help finish an= d validate new features * Provide a location to hold new features until they are deemed ready for p= roduct integration * Provide a location to hold new features until there is a natural point in= edk2 release cycle to fully validate the new feature. From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Yao,= Jiewen Sent: Saturday, September 16, 2017 7:39 AM To: Laszlo Ersek ; Ni, Ruiyu ; Paulo= Alcantara Cc: Wu, Hao A ; edk2-devel@lists.01.org; Zeng, Star Subject: Re: [edk2] Functionality issues in UDF support Hi Laszlo and Ruiyu I can think 1 possible alternative, for your consideration only. 1) Move the feature to OvmfPkg. As such, it won't block us at this moment. Once the UDF solution has good quality, we can move it back to MdeModulePkg= . Thank you Yao Jiewen From: Laszlo Ersek [mailto:lersek@redhat.com] Sent: Saturday, September 16, 2017 12:51 AM To: Ni, Ruiyu >; Paulo Alcant= ara > Cc: Yao, Jiewen >; Wu, Ha= o A >; edk2-devel@lists.01.or= g; Zeng, Star > Subject: Re: [edk2] Functionality issues in UDF support On 09/15/17 18:40, Ni, Ruiyu wrote: > Laszlo, > Please do not add a PCD for this. Too many PCDs are no good to the projec= t. I understand that new MdeModulePkg PCDs are not liked, but what do you propose instead? If we simply revert the PartitionDxe changes, then people that want to experiment with general UDF support under OVMF won't be able to do that at all. I'm in the process of adding -D UDF_ENABLE to OvmfPkg, ArmVirtPkg, and Nt32Pkg, which would control both the FeaturePCD and the inclusion of UdfDxe in the build. If you disagree with the FeaturePCD, I can stop working on this, but I don't know what the alternative is. "Fix it immediately" is not an alternative; we can't do that. If you want to revert the change, it's your prerogative, but that will prevent everybody from testing gradual UDF improvements. (No 3rd parties build OVMF from any staging branches, so if the feature is only available on a staging branch, it might as well not exist, for the outside world.) Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel