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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3874CC433F5 for ; Fri, 29 Oct 2021 06:16:13 +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 626D960FF2 for ; Fri, 29 Oct 2021 06:16:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 626D960FF2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A778F83390; Fri, 29 Oct 2021 08:16:09 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="JkKzc4HF"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A98BD83513; Fri, 29 Oct 2021 08:16:07 +0200 (CEST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 73A5481FC6 for ; Fri, 29 Oct 2021 08:16:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pf1-x42d.google.com with SMTP id 187so8297314pfc.10 for ; Thu, 28 Oct 2021 23:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=AaNXpftnnWWVJHlNEDM4wCF+kYwUnatn4sHv1XWLO1I=; b=JkKzc4HFpQvri3eRwzCOK3lqQ5nK1aj1vx2U/4j8vOJxjPlmbkK4IQV+EWEeSFaXFF 1hPa7VE1Y7QzhaNP/81+bdOT0EU3rmSyeQ0iWEocmp3obQSe14sB/d660Cyijs0R5x2X p8RYfyXXIeTRErK281mydHI8VMFacYv1V7TK3QB70LEYFbGQNLw4Q+VWzPvqaiCNcwy6 riTg66v6lT48d2mPn5CvFUbDJJ8NxQNHoiFONmCtE/ziaWjXwlsiUvABJZxVFHq7mQKM 0908KExehvF+DywYgXKjC7s15c7EkaRepQ6daGo9FGmygLYOqSXwkvgLaoXEU0LSm53O zm3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=AaNXpftnnWWVJHlNEDM4wCF+kYwUnatn4sHv1XWLO1I=; b=6+i6Ele/QZek7QPg4vfB5dD3r5iPWZuIarhMoTX7DmH9iTA3fLesuEA/OnJT3ah5uG UWsiST7euGeT91k4i5XUhdcTdmVI3NqZ6u5eSfEech9Elo+nb5FDYQqR97amDCbAAhG9 uKgeaUn4pZVcEzc2XQMMw4pglncgzrfZt0WAehC9FZ1Dh6r88SX2ngE8bWtQ85tCpBc7 nVc7uBRbjjxIfkU6CSdAgzHs78lhbGtZlFBzUR42wD9qEtR0o8mYtyG1wa+qendFvCYv qIOdN/w2RKaZeOF5JXvxmUr2+tcc4pVDBhtUtafzq4Fd+TqhKJtySQuAigN2DHGU03Dl pMkQ== X-Gm-Message-State: AOAM532Qx8Vu5cfDj6QXBA1ytg6s7mpW+bjKkfV6yH4wZwtObiXSUWdZ DgaNPc/cR6Auy+UlbGhhvjlNXg== X-Google-Smtp-Source: ABdhPJzEQUC/Je3cnwjTpKt4wdSOwUn/yc41PSEZ3pRVDF/9VrGYQoQC7rmhE7Pew7iDzdH302G0RA== X-Received: by 2002:a05:6a00:1a0d:b0:47c:34a0:e2e4 with SMTP id g13-20020a056a001a0d00b0047c34a0e2e4mr8943434pfv.55.1635488161740; Thu, 28 Oct 2021 23:16:01 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:99fd:f5c5:d3a8:a6cf]) by smtp.gmail.com with ESMTPSA id f8sm4700438pjq.29.2021.10.28.23.15.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Oct 2021 23:16:00 -0700 (PDT) Date: Fri, 29 Oct 2021 15:15:56 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: Simon Glass , Tom Rini , U-Boot Mailing List , Ilias Apalodimas , Alex Graf Subject: Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION Message-ID: <20211029061556.GD33977@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , Simon Glass , Tom Rini , U-Boot Mailing List , Ilias Apalodimas , Alex Graf References: <20211012151417.GZ7964@bill-the-cat> <20211013013217.GC43695@laputa> <20211014080316.GA22860@laputa> <20211028085217.GA98815@laputa> <111f3160-3b5e-302e-c0ca-86c66093207e@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <111f3160-3b5e-302e-c0ca-86c66093207e@gmx.de> 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 Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote: > > > > I agree with Heinrich that we are better to leave BLK as it is, both > > in name and meaning. I think maybe I am missing the gist of your > > argument. > > > > If we use UCLASS_PART, for example, can we have that refer to both s/w > > and h/w partitions, as Herinch seems to allude to below? What would > > the picture look like the, and would it get us closer to agreement? > > In the driver model: > > A UCLASS is a class of drivers that share the same interface. > A UDEVICE is a logical device that belongs to exactly one UCLASS and is > accessed through this UCLASS's interface. Please be careful about "accessed through" which is a quite confusing expression. I don't always agree with this view. > A hardware partition is an object that exposes only a single interface > for block IO. > > A software partition is an object that may expose two interfaces: one > for block IO, the other for file IO. Are you talking about UEFI world or U-Boot? Definitely, a hw partitions can provide a file system if you want. It's a matter of usage. I remember that we had some discussion about whether block devices on UEFI system should always have a (sw) partition table or not. But it is a different topic. > The UEFI model does not have a problem with this because on a handle you > can install as many different protocols as you wish. But U-Boot's driver > model only allows a single interface per device. Up to now U-Boot has > overcome this limitation by creating child devices for the extra interfaces. > We have the following logical levels: > > Controller | Block device | Software Partition| File system > ----------------+--------------+-------------------+------------ > NVMe Drive | Namespace | Partition 1..n | FAT, EXT4 > ATA Controller | ATA-Drive | | > SCSI Controller | LUN | | > MMC Controller | HW-Partition | | > MMC Controller | SD-Card | | > USB-Node | USB-Drive | | > > In the device tree this could be modeled as: > > |-- Controller (UCLASS_CTRL) > | |-- Block device / HW Partition (UCLASS_BLK) (A) > | | |-- Partition table (UCLASS_PARTITION_TABLE) (B) > | | |-- Software Partition (UCLASS_BLK) > | | |-- File system (UCLASS_FS) > | | > | |-- Block device (UCLASS_BLK) > | |-- File system (UCLASS_FS) I don't know why we expect PARTITION_TABLE and FS to appear in DM tree. What is the benefit? (A) and (B) always have 1:1 relationship. I also remember that you claimed that not all efi objects(handles and protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding U-Boot counterparts in our 2019 discussion. If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE, which should support other type of hw partitions as well? |-- eMMC controller (UCLASS_MMC) | |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?) | |-- Block device / HW Partition:user data (UCLASS_BLK) | | |-- Partition table (UCLASS_PARTITION_TABLE) | | |-- Software Partition (UCLASS_BLK) | | |-- File system (UCLASS_FS) | | | |-- Block device / HW Partition:boot0 (UCLASS_BLK) | |-- Block device / HW Partition:boot1 (UCLASS_BLK) ... | |-- eMMC device2 / Physical media (UCLASS_HW_PARTITION_TABLE?) |-- scsi controller (UCLASS_SCSI) | |-- scsi disk / Physical media (UCLASS_HW_PARTITION_TABLE?) | |-- scsi LUN1 (UCLASS_HW_PARTITION_TABLE?) | | |-- Partition table (UCLASS_PARTITION_TABLE) | | |-- Software Partition (UCLASS_BLK) | |-- scsi LUN2 (UCLASS_HW_PARTITION_TABLE?) ... (Here I ignored scsi buses/channels which make things more complicated.) This kind of complex hierarchy doesn't benefit anybody. -Takahiro Akashi > UCLASS_PARTITION_TABLE would be for the drivers in disk/. > UCLASS_FS would be for the drivers in fs/. > UCLASS_BLK will be for any objects exposing raw block IO. A software > partition does the same. It is created by the partition table driver as > child of the partition table udevice. > > In this model an eMMC device will not be a UCLASS_BLK device because it > does not expose block IO. It is the hardware partition that exposes this > interface. > > The suggested model will allow a clean description of nested partition > tables. > > In the UEFI world the software partition and its file system must be > mapped to a single handle with device path node type HD(). For the > parent block device we may create a child handle with partition number 0 > (HD(0)). For the partition table we will not create a handle. > > Best regards > > Heinrich