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 D209A21D492C5 for ; Thu, 14 Sep 2017 22:36:55 -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 v8F5beSN011117 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Sep 2017 22:37:42 -0700 Date: Fri, 15 Sep 2017 02:37:32 -0300 User-Agent: K-9 Mail for Android In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BA420DF@SHSMSX151.ccr.corp.intel.com> References: <734D49CCEBEEF84792F5B80ED585239D5BA4206B@SHSMSX151.ccr.corp.intel.com> <081B7D33-9F33-40CE-B569-62CC8C204B56@zytor.com> <734D49CCEBEEF84792F5B80ED585239D5BA420DF@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: 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 05:36:56 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On September 15, 2017 2:08:28 AM GMT-03:00, "Ni, Ruiyu" wrote: >Hi Paulo, >The responsibility of PartitionDxe driver is to partition the physical >BLK (the entire CDROM) >into logical BLKs (one BLK for each volume)=2E >It doesn't make sense to create a child BLK handle which still covers >the entire CDROM=2E >So as I suggested in below, PartitionInstallUdfChildHandles() should >contain a for-loop to iterate >all the volumes in the CDROM, and create child BLK handle for each >volumes, but skipping Eltorito volume=2E Ah, makes sense to me now=2E Thanks for clarifying it=2E So I agree with y= ou=2E In whatever you guys decide to do with it, count on me to give some help= =2E Thanks! Paulo > >Thanks/Ray > >> -----Original Message----- >> From: Paulo Alcantara [mailto:pcacjr@zytor=2Ecom] >> Sent: Friday, September 15, 2017 12:58 PM >> To: Ni, Ruiyu ; Laszlo Ersek >> Cc: edk2-devel@lists=2E01=2Eorg; Wu, Hao A ; = Zeng, >Star >> >> Subject: Re: Functionality issues in UDF support >>=20 >>=20 >>=20 >> Hi Ray, >>=20 >> 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 >>=20 >> Right=2E >>=20 >> > >> >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-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 >> >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 >>=20 >> It seems that PartitionInstallUdfChildHandles() indeed skips the >ElTorito >> partitions otherwise you'd see the "=2E=2E=2E/CDROM(0x1)/VenMedia()" an= d >> "=2E=2E=2E/CDROM(0x0)/VenMedia()" device paths *also* in the mapping >output=2E >>=20 >> If I understand correctly, the problem is that when we create a child >handle >> 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()) >>=20 >> So, the logic of skipping of ElTorito partitions in >> PartitionInstallUdfChildHandles() is not enough=2E Unfortunately we >can't >> handle UDF bridge disks (ElTorito + UDF) entirely in >> PartitionInstallUdfChildHandles() -- we should probably also skip UDF >device >> paths in PartitionInstallElToritoChildHandles()=2E >>=20 >> Does it make sense to you, Ray? Thanks for raising this up=2E >>=20 >> Paulo >>=20 >> > >> >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 --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E