From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 0C9F221E49BC6 for ; Tue, 22 Aug 2017 15:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1503441419; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dCla3vuRJx94sd5UGWKqDuylhK6DQ6Ksg+ARzyoiPUM=; b=k7fNTgLbdqfjli0FiK2a/t+AFkKqiaPaFwkjQs47tJIdoOQEm/TABjM6mWlFHoKA p6RW9ExftqCTOknIBlWaVowrngStAKFuHHaFvC7czZRuIaYcXs+TZa/7SB8CWMkT rYhL3uqI7jDdI8NlTmXJctWr8aakZcc/bOkSjevGZ9v/oi/uNEs3OXMo1Zi+MMSk 4KKk0FjuKzd1Rcb6Z0CxPOVqkVh2ptV5GOOui9RvfgXpsO6+jAWSrJnVv19LwyAl VJBCtP+SjZJ65uPNBSV7Ug9UsQEjHTdT9m/lC70kxNRaCXy99AwGrqgxa9FbiXPb TrmY3hdgSiuFiMzUsJyhLQ==; Received: from relay26.apple.com (relay26.apple.com [17.171.128.107]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 20.25.05744.B02BC995; Tue, 22 Aug 2017 15:36:59 -0700 (PDT) X-AuditID: 11ab0219-8e5ff70000001670-4d-599cb20b4acd Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by relay26.apple.com (Apple SCV relay) with SMTP id 0D.0D.30418.B02BC995; Tue, 22 Aug 2017 15:36:59 -0700 (PDT) MIME-version: 1.0 Received: from [17.234.170.227] by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OV3007M3YTKXRA0@ma1-mmpp-sz09.apple.com>; Tue, 22 Aug 2017 15:36:59 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: Date: Tue, 22 Aug 2017 15:36:56 -0700 In-reply-to: Cc: "Ni, Ruiyu" , "edk2-devel@lists.01.org" , "Dong, Eric" , "Wu, Hao A" , Jordan Justen , "Gao, Liming" , Mike Kinney , Laszlo Ersek , "Zeng, Star" To: Paulo Alcantara References: <20170820181557.28761-1-pcacjr@zytor.com> <734D49CCEBEEF84792F5B80ED585239D5B9F3CD8@SHSMSX104.ccr.corp.intel.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42IRXN2Qrcu9aU6kwa6rfBZ7Dh1lttj8Itji 6q1fTBY7rvWzWCw7toPFYsW9DewWHR3/mCz2vf7IaPGyZzW7xb5eawcuj8V7XjJ5dM/+x+Lx ft9VNo8TLV9YA1iiuGxSUnMyy1KL9O0SuDIO/vvGUnC3pmLNqoQGxgXZXYycHBICJhJT3l1i 7mLk4hASWM8ksXXTDGaYRP/KP+wQicOMEveXrGIDSfAKCEr8mHyPBcRmFgiTeDRpA5gtJPCN UWLj0xQQW1hAXOLdmU1gg9gElCVWzP/ADtFrIzHt8B92iBoXiSmHtjCC2CwCqhLLLjWB2ZwC thK/OxaCXcQs8IZJ4s6Dy6wgCREBNYnLe+6yQiybwSTR8yQN4lJZiVuzIV6QEHjOJjF35WfG CYxCs5AcOwvJsRC2lsT3R61ANgeQLS9x8LwsRFhT4tm9T+wQtrbEk3cXWBcwsq1iFM5NzMzR zcwzMtVLLCjISdVLzs/dxAiONibJHYxfXxseYhTgYFTi4bWwnhMpxJpYVlyZe4hRmoNFSZy3 aPvMSCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M/dzSifdeB/+wOu+vUfsp6NTLO1p6V90l ixvT1lxd8sO0p5c5lsN3xqs3ZVsnczHrG3w9EbX07aGFwpUPv/kIzCwJsRCMPr98zk7FDc63 HpXNqGk66c3teLxugcKPdTO5gjoXiCyL0f1///IJqY/9i97sU3vDU8zxd+Zj761/FLe+m+QU GbnUUImlOCPRUIu5qDgRACQFPqOXAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUiuLphuy73pjmRBqvecVrsOXSU2WLzi2CL q7d+MVnsuNbPYrHs2A4WixX3NrBbdHT8Y7LY9/ojo8XLntXsFvt6rR24PBbvecnk0T37H4vH +31X2TxOtHxhDWCJ4rJJSc3JLEst0rdL4Mo4+O8bS8Hdmoo1qxIaGBdkdzFyckgImEj0r/zD 3sXIxSEkcJhR4v6SVWwgCV4BQYkfk++xgNjMAmESjyZtALOFBL4xSmx8mgJiCwuIS7w7s4kZ xGYTUJZYMf8DO0SvjcS0w3/YIWpcJKYc2sIIYrMIqEosu9QEZnMK2Er87ljIDLKYWeANk8Sd B5dZQRIiAmoSl/fcZYVYNoNJoudJGsSlshK3Zl9insDIPwvJfbOQ3Adha0l8f9QKZHMA2fIS B8/LQoQ1JZ7d+8QOYWtLPHl3gXUBI9sqRsGi1JzESiMzvcSCgpxUveT83E2MkOjI3sF48p7Z IUYBDkYlHl4L6zmRQqyJZcWVuYcYJTiYlUR4lVuAQrwpiZVVqUX58UWlOanFhxilOViUxHkl iyZHCgmkJ5akZqemFqQWwWSZODilGhgZvZjqJmUbvIhm76hIXvB7waNlV7sevH+8XqFoTd// 96Ip3CqBF+UCXmdHme//tWNK+bIKPZ2AawdaNx/8Jrb5ymxGp4jrLXvdDqdPvGXHfFPlbKXR xveyr5bbXMvxeW6+tF+rOJc1LW5xJ7OXV9bltCV2uQ9YNrLtiXf7VrFwVeJL8zcBGXxKLMUZ iYZazEXFiQA+Ty0WigIAAA== X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: [PATCH v2 0/6] read-only UDF file system 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: Tue, 22 Aug 2017 22:34:27 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > On Aug 22, 2017, at 10:56 AM, Paulo Alcantara wrote: > > Hi, > > On 8/22/2017 2:21 PM, Andrew Fish wrote: >>> On Aug 22, 2017, at 6:14 AM, Paulo Alcantara wrote: >>> >>> Hi, >>> >>> I do apologize my late replies. At the moment, I'm only able to work on this during my free time. Thank you all for the reviews! >>> >>> FWIW, my comments below. >>> >>> On 8/20/2017 11:29 PM, Ni, Ruiyu wrote: >>>> Paulo, >>>> 1. Could you please run the ECC check tool (BaseTools\Source\Python\Ecc\) >>>> "CRC" might need to be replaced with "Crc". >>>> I also noticed some TAB key in file content. >>> >>> Sure. >>> >>>> 2. Your current implementation uses HARD_DRIVE_DEVICE_PATH. >>>> But with: >>>> SignatureType = SIGNATURE_TYPE_UDF >>>> MBRType = MBR_TYPE_PCAT >>>> Signature = * >>>> And later UdfDxe driver checks the SignatureType and MBRType. >>>> I am not sure if it would be better to put the definitions in UEFI Spec, >>>> since they are referenced by different modules. >>>> I also noticed you use PARTITION_TYPE_OTHER for PartitionInfo. >>>> When proposing to UEFI Spec, this also needs to be considered, >>>> for example, add PARTITION_TYPE_UDF to spec. >>> >>> Yes - I agree with you. My only concern is that UEFI specification doesn't either support UDF or there is any interest in supporting it, so by proposing an additional type for something that shouldn't be supported, might not work out. >>> >>> (Andrew, any thoughts?) >>> >> The enum space is owned by the UEFI spec and should never be extended outside the scope of the spec. Its not good to have an implementation running around that is not in a released spec, as it it is a future compatibility risk. >> Does the UDF actually start with a real MBR? If so is it possible to define a 32-bit MBR signature to indicate UDF. If not it should probably be a device path node like CD-ROM. > > No. But it's possible to create an UDF file system inside a MBR/GPT partition so it would end up having a valid HARDDRIVE_DEVICE_PATH and no fake MBR device path wouldn't be created or needed at all. > > The only problem is that when we find an UDF file system which isn't part of either a MBR or a GPT partition table, and then there is no matching device path for using with it. > Most current file systems don't have device paths. CD-ROM is the exception, not the rule as it is an overlay of another file system type. Generally the MBR or GPT partition node just indicates a range of bytes on the disk. The file system driver starts looking at byte 0 of the partition to find known structures to decide if it can start on the disk. For example this is the algorithm in the FAT driver: https://github.com/tianocore/edk2/blob/master/FatPkg/EnhancedFatDxe/Init.c#L198 . I think this is kind of historical and makes the file system work on media with no partition, and media with partitioning the same way. Thanks, Andrew Fish >> You can all ways use the Vendor-Defined Media Device Path since it has GUID there is no risk of collision. > > Right. If you guys agree, I'll start using the vendor-defined device path again for all the cases where an UDF file system is found -- avoiding to break anything that's unrelated. > > Thanks Andrew! > > Paulo