From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 767BA20945B9C for ; Sat, 16 Sep 2017 13:18:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9C2C0C0587E3; Sat, 16 Sep 2017 20:21:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9C2C0C0587E3 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-8.rdu2.redhat.com [10.10.120.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1851B60BF1; Sat, 16 Sep 2017 20:21:05 +0000 (UTC) To: "Yao, Jiewen" , "Ni, Ruiyu" , Paulo Alcantara Cc: "Wu, Hao A" , "edk2-devel@lists.01.org" , "Zeng, Star" 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> From: Laszlo Ersek Message-ID: <391eff00-c91b-5612-2099-a230eb23ed97@redhat.com> Date: Sat, 16 Sep 2017 22:21:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A9BC398@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Sat, 16 Sep 2017 20:21:07 +0000 (UTC) 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: Sat, 16 Sep 2017 20:18:06 -0000 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Jiewen, On 09/16/17 01:38, Yao, Jiewen wrote: > 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. the urgent issue is not with the UdfDxe driver; a platform can simply choose not to include the UdfDxe driver. The problem is that the UDF-related changes in PartitionDxe have caused a regression in PartitionDxe, and PartitionDxe is something that all platforms must include. The feature PCD that I suggested would turn the (currently buggy) UDF logic in PartitionDxe into a no-op by default. Thanks Laszlo > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Saturday, September 16, 2017 12:51 AM > To: Ni, Ruiyu ; Paulo Alcantara > Cc: Yao, Jiewen ; Wu, Hao A ; edk2-devel@lists.01.org; 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 project. > > 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 >