From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36FB8C07E99 for ; Fri, 9 Jul 2021 05:28:07 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4D91461002 for ; Fri, 9 Jul 2021 05:28:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D91461002 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B3297831F7; Fri, 9 Jul 2021 07:28:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=gmx.net header.i=@gmx.net header.b="Fdo3y4jA"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0446A83202; Fri, 9 Jul 2021 07:28:03 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E9151831BA for ; Fri, 9 Jul 2021 07:27:59 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1625808474; bh=PUv3JrmmLLT1O22yx8jqMCDx3Srnpf1fV61Qv1ajGYo=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Fdo3y4jA6+5DmTAprmpZO5eW/jOzuycmUGxt5ON3JbRhgTls6PfYspMYSIAryt8fQ ETMj8iQ2bA3rjvao9q/zT4AueJ881nUpeePZp5lALjTXRdL2b6CWK/Id3nPM1MfmBv +sgGY3X+9ai8gX7iKiRvoP531mE5FNsb2KYZuVD0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.35] ([88.152.144.157]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mjj87-1lKzWD2S9T-00lDqK; Fri, 09 Jul 2021 07:27:54 +0200 Subject: Re: RFC: Devices for files and partitions To: AKASHI Takahiro , Simon Glass , U-Boot Mailing List , Tom Rini , Ilias Apalodimas , Marek Vasut , Sean Anderson , Marek Beh??n References: <20210709024437.GA70106@laputa> From: Heinrich Schuchardt Message-ID: Date: Fri, 9 Jul 2021 07:27:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210709024437.GA70106@laputa> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+CdQfYfZwKdujmebFEEYaMdtbl2btDCSZrblJiJ07tEdDEPtCtv gwf5BWtsQgKFLVaEK6bZZO0Btr5PYpAVt89it8+a3/bHau0ZPJ4bBdlRgw+gCayJPQc83lh sSMaPhAON+7dDCd5Izoh1fQj5fo2wt/AnC8+dc3Ny1TQZF0c0dFomey263pV6OfE+t2LWLd uZ1SMj6n0o9POUb8cyhBw== X-UI-Out-Filterresults: notjunk:1;V03:K0:V3IgoGXsdGo=:pvJrkh/DkVQlkKzCLYXnJ4 jtLCaiSecuVntllkhQez1xoALViYrvAhOalp2bRI0PYsWLvU+fzQOll0efPlA7vzSdFo2rGe6 XNOUVklNTCkrswSd12QdjkwWElOqbOxuENqlKeXyKzDlsEHaLK12NtjHAbTGH/0SoUj+sndwl CowVpCuAsAxSJJ5VgVcS8bQmUcprBJ232c95YDnozPP5v4jMGMmgs1Ba95rpI7kG6zW2xG+3z dyXyNA+j4HFYSFno+IUjCiIjK43uMeGxlGzAHIWm3BK8QGVZUcHsXrljls1wX3hNtTARSDc7l Z9VRtBZXm+vnNk3InOR6TpGAMvhReOr/HzGMJqF0eYjhI7WRv0M04OWWGgZ1Ml/Y/MaDdaCtE XPg86u8GKypC37sqwqeiQKixLszLRLeg7sRWbRlEGcYsUjHAwLkWW9iJGmqfXYFaRGG6vhvYt zDehFO2Uxv7C027AlnuBrOZU/3l7UrcIRq1uYpybH9U2oF/JnYhNYi5FaooIM/g1oFOGVRj9v Lh5nzZyKVZnMyz9yyyY+31gFurHHMFGKtAo3qUcrIVW3HHtI27lcNz2ygm01nMz3DfgYVlO0Z UkrJaqIBHKLCOasPV3vMInbMdwflL+4oKd7d8D8ii1yPqGDlw3wFJComcyM3fG95ftjf4MNop qCyUPV8PUHLIiQmJ9/lsiOyZNf73nbixmPrFkc4r33AIjLiaEqJ0e0H2shmm4V8nWruXlZIhF J1csLjBvlvY5D9Y0XUy1DnI84Q+ye4pJ3YrvhKPbILy+nez2Fj1jhLPOXqJXEG8Q/wAA1tmn2 r97ISTnmJxplwr61+tdloPNg1l5xWLlFDTJh5a4mgV99GIedxUMisIbx4izekr+DbFaojZCyl zbyT+veJpI58NxzD8JAj/alocKz33JExK43rllr0/P9PBbQiDprSjq7veBYbzOtf3QlWv9tvj ocvwPAiZAiI77zD/wFrTvM9MA9GSW7SNB17oqFuTvMx4pGPHnQYG6jSYu3K8lvYmUOwvxFnCc e4xWWh+7KvBGjcAVQXn4VFce2IfldSoAEE/dLzz5UOTc1zL8SfG2qr5JQq8DD0k46s+DizFMj 2S5ZB/yskEK4UB42f9Ou4OD1rDNxaAKrm2s X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 7/9/21 4:44 AM, AKASHI Takahiro wrote: > On Tue, Jul 06, 2021 at 05:05:19PM -0600, Simon Glass wrote: >> Hi, >> >> At present U-Boot avoids the concept of 'opening' a file. Being in a >> bootloader environment, it is normally better to take the action >> immediately and avoid any caching, for example, since there is no >> background task to clean up afterwards. >> >> Having said that, the concept of a file is quite useful, for example >> to write the output of a command to a file, or to open a file and read >> it a line at a time. >> >> Another case has come to light in that EFI wants to access files using >> a file handle. This currently uses parallel data structures and does >> not map very well in U-Boot. Not having a file descriptor slows down file operation because for each individual access to a file we * read the partition table * look up the file in the directory structure If you only use the 'load' command, this does not matter because there is only a single read. But in the UEFI sub-system we use multiple API call= s: * open the volume * open the file * read the file size (for buffer allocation) * read the file The file descriptors in the UEFI sub-system only hold device, partition ID, file path. >> >> Finally, partitions has a similar issue, where defining them as a >> device can have benefits, e.g. to specify the device to use directly, >> rather than with the 'type dev:part' approach, perhaps providing them >> in the devicetree, etc. >> >> For the above reasons, I propose that we implement, as an option, >> support for files and partitions within driver model. With partitions as devices we will have to read the partition table only once when the block device is probed. - For the UEFI sub-system we need all block devices to be probed before calling the UEFI binary (e.g. GRUB). > > +1 > > # Nobody has commented yet :) > > Regarding a "file (or file descriptor)", we have already implemented > the same concept in efi_loader. So technically, it won't be a hard-work. > Regarding "partitions as udevice," I have posted an experimental > patch [1]. So it must also be feasible. Our UEFI file descriptor is not helpful because it does not buffer the relevant data to speed up file access. E.g. for the FAT driver a file descriptor could buffer some information from the directory entry (file attributes, dates) and some from the FAT table (assigned extends). > > One of my concerns is what benefit end users may enjoy. Improved performance. Best regards Heinrich > > -Takahiro Akashi > > [1] https://lists.denx.de/pipermail/u-boot/2019-February/357937.html > https://lists.denx.de/pipermail/u-boot/2019-February/357934.html > >> Regards, >> Simon