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 36EEC21E9781E for ; Fri, 15 Sep 2017 09:48:27 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1EC0D883CE; Fri, 15 Sep 2017 16:51:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1EC0D883CE Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-125-162.rdu2.redhat.com [10.10.125.162]) by smtp.corp.redhat.com (Postfix) with ESMTP id 681865E24A; Fri, 15 Sep 2017 16:51:25 +0000 (UTC) To: "Ni, Ruiyu" , Paulo Alcantara Cc: "Yao, Jiewen" , "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> From: Laszlo Ersek Message-ID: Date: Fri, 15 Sep 2017 18:51:24 +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: <11481899-6F36-4877-B4FF-732B2781F3CB@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 15 Sep 2017 16:51:27 +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: Fri, 15 Sep 2017 16:48:27 -0000 Content-Type: text/plain; charset=ISO-8859-2 Content-Language: en-US Content-Transfer-Encoding: 7bit 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