From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.zytor.com (terminus.zytor.com [65.50.211.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 F35AD20945C17 for ; Thu, 14 Sep 2017 21:57:07 -0700 (PDT) Received: from [192.168.15.2] (177.18.107.39.static.host.gvt.net.br [177.18.107.39] (may be forged)) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id v8F4voGE028628 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Sep 2017 21:57:52 -0700 Date: Fri, 15 Sep 2017 01:57:41 -0300 User-Agent: K-9 Mail for Android In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BA4206B@SHSMSX151.ccr.corp.intel.com> References: <734D49CCEBEEF84792F5B80ED585239D5BA4206B@SHSMSX151.ccr.corp.intel.com> MIME-Version: 1.0 To: "Ni, Ruiyu" , Laszlo Ersek CC: "edk2-devel@lists.01.org" , "Wu, Hao A" , "Zeng, Star" From: Paulo Alcantara Message-ID: <081B7D33-9F33-40CE-B569-62CC8C204B56@zytor.com> 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 04:57:08 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ray, On September 15, 2017 12:33:04 AM GMT-03:00, "Ni, Ruiyu" wrote: >Paulo, >Before raising my questions, I'd like to confirm that for a single >CD/DVD in UDF format, there might be multiple volumes=2E >One of the volume could be Eltorito type=2E >If my understanding is correct, please continue reading below=2E Right=2E > >We found below mapping table using "map -r" shell command in a platform >with only PartitionDxe change and without UdfDxe driver=2E >It's a bug that and are created=2E Actually they are >identical to and =2E > >--- 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-49= 96-8956-73CDA326CD0A) > BLK6: Alias(s): >PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/VenMedia(C5BD4D42-1A76-49= 96-8956-73CDA326CD0A)/CDROM(0x0) > FS2: Alias(s):CD1a65535ab:;BLK7: >PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/VenMedia(C5BD4D42-1A76-49= 96-8956-73CDA326CD0A)/CDROM(0x1) >--- End of mapping table --- > >After investigation, I found the UDF logic in Partition driver doesn't >truly skip the Eltorito volume=2E >The code flow is like below: > > 1=2E is created by ScsiDiskDxe driver=2E > 2=2E By passing to PartitionDxe Start() >* and are created by PartitionDxe driver, by >PartitionInstallElToritoChildHandles()=2E >* is created by PartitionDxe driver, by >PartitionInstallUdfChildHandles()=2E > 3=2E By passing to PartitionDxe Start() >* and are created by PartitionDxe driver, by >PartitionInstallElToritoChildHandles()=2E > >I think step 2=2Ea is not correct if my understanding to UDF is correct= =2E >The PartitionInstallUdfChildHandles() should iterate >all volumes in the media and creates the child BLK handle for each >volume, but skipping Eltorito volume=2E > >Instead, the current implementation just creates one child BLK handle >for the entire media=2E >To avoid reclusively creating child BLK handle, the >PartitionInstallUdfChildHandles() contains a logic to do nothing when >the handle is created by ParititonDxe driver=2E The logic is not needed >when the implementation follows my suggestion above=2E >Due to this, step 3=2Ea creates the additional but shouldn't-exist BLK >handles and =2E > >UdfDxe driver is supposed to Start() on each volume and produce >SimpleFileSystem protocol=2E It seems that PartitionInstallUdfChildHandles() indeed skips the ElTorito = partitions otherwise you'd see the "=2E=2E=2E/CDROM(0x1)/VenMedia()" and "= =2E=2E=2E/CDROM(0x0)/VenMedia()" device paths *also* in the mapping output= =2E If I understand correctly, the problem is that when we create a child hand= le for an UDF volume, Partition driver will execute again, parse the newly = created UDF handle, find again an ElTorito partition and then install a new= child handle (VenMedia()/CDROM()) So, the logic of skipping of ElTorito partitions in PartitionInstallUdfChi= ldHandles() is not enough=2E Unfortunately we can't handle UDF bridge disks= (ElTorito + UDF) entirely in PartitionInstallUdfChildHandles() -- we shoul= d probably also skip UDF device paths in PartitionInstallElToritoChildHandl= es()=2E Does it make sense to you, Ray? Thanks for raising this up=2E Paulo > >Do you agree with my above suggestions? > >Laszlo, >I understood your needs of this UDF support=2E But as you can see there >are many build failures and even functionality issues due to this >support=2E >I am not sure how the other open source project handles such cases=2E >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=2E >What's your suggestion? > >Thanks/Ray --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E