Received: by 2002:a05:7412:cfc7:b0:fc:a2b0:25d7 with SMTP id by7csp998067rdb; Mon, 19 Feb 2024 00:13:17 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUiJHdlstlBFTcT6m2WA6NEvOBdCtvLmDxE7cyQL15doDIefdJ1SgDk1EAtThkwHg/9eo47Yzl/bNYugFC9GFh79GOkbtE+lCePIaA7VA== X-Google-Smtp-Source: AGHT+IH0wcyFrDRe1GVzTMJqEuWcGnt3TFekBxL5gNuMpcXhJeeA8chqAigfSf0w0xIcw82BpOBO X-Received: by 2002:a05:6870:7b4d:b0:21d:56af:4c48 with SMTP id ji13-20020a0568707b4d00b0021d56af4c48mr13230813oab.49.1708330396761; Mon, 19 Feb 2024 00:13:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708330396; cv=pass; d=google.com; s=arc-20160816; b=lNVWdn5d+kKOp2lAFAASsxPdyEAPOGSt13tvORXD/3QVLfCkdjuyqOu0OdFmphk1Lb 6T/TWPSOqmB83jnm/Lplpc8Um7nsNCAxSLAN2udOBk1iVjwGluHKSXYkkQHWkCR60NH9 mM6ybEGG6YpzTrxzL2qlzQC+D71z9fUIOMbGuu8vUsjPN33JO9HQi+/eX4tY1hofIv1I rr8mapIHQ9vC3KftAMHHzW0u47HrF5NYkm+cHVrxs1Q25MErHM6d/JhU4cc8mBFd2hvk l5UeBcooa+I4imc1ggObg7AHn9x56GxdxFIwrupdeBxquGxQCjwgBC2GgSj1Vknvhjqa 51rw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=cpRMBy7hZ7FKQHYZ8+2Ocd445Fda/mXEQ19svTRz4Og=; fh=gSAf1dIJL8o0Hxrvb5puusamUfaU9caIDxPjJcn7L6Q=; b=CP6eghm/p35l5D+48JpyPQAE2TDjpSH1YTBXNVqCxOYhnc7PIfTokNRt58iL5DjHlr RjG5NcdRnHNHxkYzTKytjytZei/rd+S5vs3Cu0YkKI4hKqejaWkOD6USUj5nrP2OH5Nn +Z+jpB0KdV9PCTrg+p4RSQFXCGTfdnxt+eq1SWjUT1zovAdyILeAfpUCAsH2fiecYJ9t ES58Q9+ChMfu3hZT6afwa9k1EExekZtqsP25BdjWHqUDNHzzBWd9cpmOZ3l6qYO9ZrNd nOUBI2nt9D8LbJ6O4s36mbXUuslyw4U8TlMl5scGHYS23Efv+oDMIdd9/y7Mgsa4ip+O BrVQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=jhfZg1UW; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-70911-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70911-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id p19-20020a639513000000b005dc42014e30si4163273pgd.692.2024.02.19.00.13.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Feb 2024 00:13:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-70911-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=jhfZg1UW; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-70911-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-70911-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 6CC81281F58 for ; Mon, 19 Feb 2024 08:13:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3D4D9210E1; Mon, 19 Feb 2024 08:13:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="jhfZg1UW" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 459A52135C; Mon, 19 Feb 2024 08:13:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708330387; cv=none; b=ZVO0Vh8ACLTsOSgcqDsgtRDIo21pK060sDfQdLksZ4IemqS/sGxhSn9fKIoemeNKDXIejnT2Av/lScyHL1bcvk/Q0WN3+eIwk+iRvT+5mz1jjycr14nzL7eRRp51kfs1y2FZH15D5UjwVSH1OsJAKHVNa+clIk2ETsK0BxHF8L8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708330387; c=relaxed/simple; bh=1w3J45VRLDLeMHSNQ1LNWwVGXu9vFKXbgM2hR+lw2cU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K+6q6uEs7CqInmV+xi6GVVX0wCB/k8RDgzZiq51uTI9J1XDXbsH4i+HxFvY8sAI3pcSdTMuTcrQc/2Qg1vrefjzRBOj6FZFXrNgVOTTVSHjgsyAAo4oWoCjSXIhbPcLiS1KKXOkL8e71Jnm/W0tKWj87ab+syIO/l9zFKH0ZSHc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=jhfZg1UW; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59439C433C7; Mon, 19 Feb 2024 08:13:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1708330386; bh=1w3J45VRLDLeMHSNQ1LNWwVGXu9vFKXbgM2hR+lw2cU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jhfZg1UWk/gIXkIAdbPlphVgddgqd1ksAhGXvha+wO8pNKb1DMovmkeVam5cOXg4V ZjobisTZkClepNOBnY4pK1TvUg5MRJ46gK7Jb8S9Dh+4mNUj2diDLWUzWREqyw4PD8 PzqZuInLMj6WOi48A3lXFEc8a0b7BDAuxcmKG4ao= Date: Mon, 19 Feb 2024 09:13:03 +0100 From: Greg Kroah-Hartman To: Michael Grzeschik Cc: Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , Jonathan Corbet , v9fs@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH v2 3/4] usb: gadget: legacy: add 9pfs multi gadget Message-ID: <2024021911-facelift-graveyard-0760@gregkh> References: <20240116-ml-topic-u9p-v2-0-b46cbf592962@pengutronix.de> <20240116-ml-topic-u9p-v2-3-b46cbf592962@pengutronix.de> <2024021757-geography-hacksaw-3022@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Feb 19, 2024 at 02:48:43AM +0100, Michael Grzeschik wrote: > On Sat, Feb 17, 2024 at 04:59:28PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Feb 02, 2024 at 01:05:12AM +0100, Michael Grzeschik wrote: > > > Add the newly introduced 9pfs transport gadget interface with an new > > > multi composed gadget together with acm and eem. > > > > > > When using this legacy module, it is also possible to > > > mount the 9PFS usb dir as root filesystem. Just follow the > > > instrucitons from Documentation/filesystems/9p.rst > > > > Why are we adding new "legacy" gadgets? What's wrong with the "correct" > > api instead? You need a lot of justification here to add something to > > an api we want to one day just delete. > > Without the legacy gadget there is no real solution to mount > the 9pfs via the gadget as rootfs. The "correct" api is configfs > which will need the user to have some filesystem to mount it to. That's what your initramfs is for. Why can't you just use that? > There is the relatively new concept of bootconfig which sounds > promising to describe an complete configfs tree from system boot. Great, but until that happens, again, just use initramfs. > However this is some future talk for now, so we would like to > stick with the legacy setup to be able to mount the 9pfs rootfs. I'd prefer to NOT add new legacy gadget drivers, and do everything possible to delete them all from the tree "soon". > > > +/* > > > + * Gadget usb9pfs only needs two bulk endpoints, and will use the usb9pfs usb > > > + * transport to mount host filesystem via usb gadget. This driver will > > > + * also add one ACM and NCM interface. > > > > Why "also"? What are those interfaces going to be used for and what do > > they have to do with 9pfs? > > They are not necessary to be used with 9pfs. But since we introduce an > new legacy module which is fully claiming the UDC, it would make sense > to leave the other endpoints unavailable but instead add some common > interfaces like ecm and acm. But if no one needs/wants them, why make this complex? Again, configfs can handle the composition of this if you need it, which is why that "new" interface was created. thanks, greg k-h