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=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 17C1DC3815B for ; Mon, 20 Apr 2020 18:02:36 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BD9D7206F6 for ; Mon, 20 Apr 2020 18:02:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="LnzLHOGL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD9D7206F6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 495ZKh5qSXzDqlD for ; Tue, 21 Apr 2020 04:02:32 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linuxfoundation.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=gregkh@linuxfoundation.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=default header.b=LnzLHOGL; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 495Tb36TvWzDqBK for ; Tue, 21 Apr 2020 00:28:47 +1000 (AEST) Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E7A96205C9; Mon, 20 Apr 2020 14:28:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587392924; bh=Xfhmbt3oILrMnmMSAOk0kNM8XdFhuXm9MUCUSzShG8g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LnzLHOGL3SfYzz4pLofCJ1ROQjqVMmfWQwIeMijgCZdRKOiLZgnrpkFWugSMer61U SUy1vwyCeMyLufrPfYFn9wMKcSES/m+B4D/DjqcEiwhebOFIg8iwdCJThhBrgF45My mDtP1iFIfm+kWnwF33LB3q5mplaFnA9YYIC790Wo= Date: Mon, 20 Apr 2020 16:28:42 +0200 From: Greg Kroah-Hartman To: Emanuele Giuseppe Esposito Subject: Re: [PATCH 6/8] simplefs: add file creation functions Message-ID: <20200420142842.GA4125486@kroah.com> References: <20200414124304.4470-1-eesposit@redhat.com> <20200414124304.4470-7-eesposit@redhat.com> <20200414125626.GC720679@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Tue, 21 Apr 2020 03:37:32 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Song Liu , linux-usb@vger.kernel.org, bpf@vger.kernel.org, "Rafael J. Wysocki" , David Airlie , Heiko Carstens , Alexei Starovoitov , dri-devel@lists.freedesktop.org, "J. Bruce Fields" , Joseph Qi , Hugh Dickins , Paul Mackerras , John Johansen , netdev@vger.kernel.org, ocfs2-devel@oss.oracle.com, Christoph Hellwig , Andrew Donnellan , Matthew Garrett , linux-efi@vger.kernel.org, Arnd Bergmann , Daniel Borkmann , Christian Borntraeger , linux-rdma@vger.kernel.org, Mark Fasheh , Anton Vorontsov , John Fastabend , James Morris , Ard Biesheuvel , Jason Gunthorpe , Doug Ledford , oprofile-list@lists.sf.net, Yonghong Song , Ian Kent , Andrii Nakryiko , Alexey Dobriyan , "Serge E. Hallyn" , Robert Richter , Thomas Zimmermann , Vasily Gorbik , Tony Luck , Kees Cook , "James E.J. Bottomley" , autofs@vger.kernel.org, Maarten Lankhorst , Mike Marciniszyn , Maxime Ripard , linux-fsdevel@vger.kernel.org, "Manoj N. Kumar" , Uma Krishnan , Jakub Kicinski , KP Singh , Trond Myklebust , "Matthew R. Ochs" , "David S. Miller" , Felipe Balbi , linux-nfs@vger.kernel.org, Iurii Zaikin , linux-scsi@vger.kernel.org, "Martin K. Petersen" , linux-mm@kvack.org, linux-s390@vger.kernel.org, Dennis Dalessandro , Miklos Szeredi , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Anna Schumaker , Luis Chamberlain , Chuck Lever , Jeremy Kerr , Daniel Vetter , Colin Cross , Frederic Barrat , Paolo Bonzini , Andrew Morton , Mike Kravetz , linuxppc-dev@lists.ozlabs.org, Martin KaFai Lau , Joel Becker , Alexander Viro Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Apr 20, 2020 at 03:57:48PM +0200, Emanuele Giuseppe Esposito wrote: > > > On 4/14/20 2:56 PM, Greg Kroah-Hartman wrote: > > On Tue, Apr 14, 2020 at 02:43:00PM +0200, Emanuele Giuseppe Esposito wrote: > > > A bunch of code is duplicated between debugfs and tracefs, unify it to the > > > simplefs library. > > > > > > The code is very similar, except that dentry and inode creation are unified > > > into a single function (unlike start_creating in debugfs and tracefs, which > > > only takes care of dentries). This adds an output parameter to the creation > > > functions, but pushes all error recovery into fs/simplefs.c. > > > > > > Signed-off-by: Emanuele Giuseppe Esposito > > > --- > > > fs/simplefs.c | 150 +++++++++++++++++++++++++++++++++++++++ > > > include/linux/simplefs.h | 19 +++++ > > > 2 files changed, 169 insertions(+) > > > > What's wrong with libfs, isn't that supposed to be for these types of > > "common" filesystem interactions? > > > > Why create a whole "new" fs for this? > > I assume you meant a new file. These new functions are used only by a few > filesystems, and I didn't want to include them in vmlinux unconditionally, > so I introduced simplefs.c and CONFIG_SIMPLEFS instead of extending libfs.c. > In this way only fs that need this code like debugfs and tracefs will load > it. Nothing "loads it", why not just make these libfs functions instead? As the difference between the two is not obvious at all, please don't make things confusing. thanks, greg k-h