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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 C4479C07E95 for ; Sun, 11 Jul 2021 00:02:19 +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 29583610CA for ; Sun, 11 Jul 2021 00:02:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29583610CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 2D53E83301; Sun, 11 Jul 2021 02:01:37 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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; unprotected) header.d=chromium.org header.i=@chromium.org header.b="mD09Jq6h"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4C80D831B2; Sun, 11 Jul 2021 02:01:22 +0200 (CEST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 736E081D48 for ; Sun, 11 Jul 2021 02:01:18 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-wr1-x430.google.com with SMTP id l7so17423418wrv.7 for ; Sat, 10 Jul 2021 17:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EmvIZVRraWHo5rAMopcQBxMwavdt7j775bRcdaYuPVs=; b=mD09Jq6hVrH61SrUq1zJGrnrJg9Z7/KbsPyvHWRZe0v4FfssttSW4nFZe+2yO536tc p2etCvO81wA6LZPRZknpAFklSCdSMBYiJcPDg/BsL96PU+5ZWfSDQPMFa7k5dKGwXBa2 DJXJUYh1zzsX5KV+rDUtwUQaencfat7VxWMuw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EmvIZVRraWHo5rAMopcQBxMwavdt7j775bRcdaYuPVs=; b=pJiI9Zn8zy/Sm/2K/hneRIoaz8m9Fhr6AyLoghHEF9NWNjRykJ0IcxmPDCKXEnAmDH 2j0MKMj9j+Toc0Dg+NpNqQORXoTxyJ/v5ClT2z+cnLzw4HzTidCfkZf0rCR5igYizBQ/ pW1wk1u+swgy0eoBWkVzB1UIS5s3Gw822WqmVLB+pqZ4MOajZYMSIaYzX4QdsumWdUcJ XwczX0fjB3TQKJCq04TYbWPdM7MJeQE7AUwjwPwKBTuPxb1qlcnrYHigab/5ZI4DrDVl 43G9P9coHtW6ubHRHOPbwZCWvs9A6PQhXTXc6c3aV62/YeP8W6CwDmLYm2PeW15aI8mr Vowg== X-Gm-Message-State: AOAM531SwD5WPaHdSzF/A1YNr6AGd1OdUaPGm3G+meg2GfFeTomzUX6K Mwjcoq/5Wna9jwQup9uyDjlmBJaBMKqXzkRq9Yz1BA== X-Google-Smtp-Source: ABdhPJyR8v1pgCUTg2U6p7kFpEjax58xoxNB0eecy6fNqKAjP32Rey5PBtm7acyzn9jCB/UFXR2yPHpHjyPfasmJNHY= X-Received: by 2002:a5d:4522:: with SMTP id j2mr12127784wra.43.1625961677746; Sat, 10 Jul 2021 17:01:17 -0700 (PDT) MIME-Version: 1.0 References: <20210709024437.GA70106@laputa> In-Reply-To: From: Simon Glass Date: Sat, 10 Jul 2021 18:01:04 -0600 Message-ID: Subject: Re: RFC: Devices for files and partitions To: Heinrich Schuchardt Cc: AKASHI Takahiro , U-Boot Mailing List , Tom Rini , Ilias Apalodimas , Marek Vasut , Sean Anderson , "Marek Beh??n" Content-Type: text/plain; charset="UTF-8" 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 Hi, On Thu, 8 Jul 2021 at 23:33, Heinrich Schuchardt wrote: > > 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 calls: > > * 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. Arguably that is a potential benefit, dependent on us implementing (write-through?) caching of this info. > > >> > >> 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). It would be better if UEFI could support lazy probing, but that's off-topic here. > > > > > +1 > > > > # Nobody has commented yet :) Thank you for commenting. > > > > 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. With a bit of effort, yes, with UEFI at least, by the sound of it. I'm not sure how much difference it would make for non-EFI use though. To me this is an internal thing, a bit like driver model, where the benefit is easier development and scripting, which might benefit end users indirectly through faster time-to-market and fewer bugs? Takahiro, since you have already started this work, do you want to continue it? I think the original patch needed a test. > > 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 Regards, Simon >