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 CE17920945C00 for ; Thu, 14 Sep 2017 20:31:55 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP; 14 Sep 2017 20:34:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,396,1500966000"; d="scan'208,217";a="1014661001" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga003.jf.intel.com with ESMTP; 14 Sep 2017 20:34:53 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Sep 2017 20:34:17 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Sep 2017 20:34:16 -0700 Received: from shsmsx151.ccr.corp.intel.com ([169.254.3.98]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.219]) with mapi id 14.03.0319.002; Fri, 15 Sep 2017 11:33:05 +0800 From: "Ni, Ruiyu" To: Paulo Alcantara , Laszlo Ersek CC: "edk2-devel@lists.01.org" , "Wu, Hao A" , "Zeng, Star" Thread-Topic: Functionality issues in UDF support Thread-Index: AdMt01KyZGagPN/kQv20rkBpZNwXqA== Date: Fri, 15 Sep 2017 03:33:04 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BA4206B@SHSMSX151.ccr.corp.intel.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: 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 03:31:56 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paulo, Before raising my questions, I'd like to confirm that for a single CD/DVD i= n UDF format, there might be multiple volumes. One of the volume could be Eltorito type. If my understanding is correct, please continue reading below. We found below mapping table using "map -r" shell command in a platform wit= h only PartitionDxe change and without UdfDxe driver. It's a bug that and are created. Actually they are identi= cal to and . --- Mapping table--- BLK2: Alias(s): PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0) BLK3: Alias(s): PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/CDROM(0x0) FS1: Alias(s):CD1a65535a1:;BLK4: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/CDROM(0x1) BLK5: Alias(s): PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/VenMedia(C5BD4D42= -1A76-4996-8956-73CDA326CD0A) BLK6: Alias(s): PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/VenMedia(C5BD4D42= -1A76-4996-8956-73CDA326CD0A)/CDROM(0x0) FS2: Alias(s):CD1a65535ab:;BLK7: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/VenMedia(C5BD4D42= -1A76-4996-8956-73CDA326CD0A)/CDROM(0x1) --- End of mapping table --- After investigation, I found the UDF logic in Partition driver doesn't trul= y skip the Eltorito volume. The code flow is like below: 1. is created by ScsiDiskDxe driver. 2. By passing to PartitionDxe Start() * and are created by PartitionDxe driver, by Parti= tionInstallElToritoChildHandles(). * is created by PartitionDxe driver, by PartitionInstallUdfCh= ildHandles(). 3. By passing to PartitionDxe Start() * and are created by PartitionDxe driver, by Parti= tionInstallElToritoChildHandles(). I think step 2.a is not correct if my understanding to UDF is correct. The = PartitionInstallUdfChildHandles() should iterate all volumes in the media and creates the child BLK handle for each volume, = but skipping Eltorito volume. Instead, the current implementation just creates one child BLK handle for t= he entire media. To avoid reclusively creating child BLK handle, the PartitionInstallUdfChi= ldHandles() contains a logic to do nothing when the handle is created by ParititonDxe driver. The logic is not needed when = the implementation follows my suggestion above. Due to this, step 3.a creates the additional but shouldn't-exist BLK handle= s and . UdfDxe driver is supposed to Start() on each volume and produce SimpleFileS= ystem protocol. Do you agree with my above suggestions? Laszlo, I understood your needs of this UDF support. But as you can see there are m= any build failures and even functionality issues due to this support. I am not sure how the other open source project handles such cases. But I am thinking maybe we could move the whole UDF support to edk2-staging= firstly and move it back after all the issues are resolved. What's your suggestion? Thanks/Ray