From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 017E5C77B61
	for <linux-kernel@archiver.kernel.org>; Fri, 28 Apr 2023 17:59:35 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1346456AbjD1R7d (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 28 Apr 2023 13:59:33 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43330 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1346338AbjD1R7b (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 28 Apr 2023 13:59:31 -0400
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E84CE4203
        for <linux-kernel@vger.kernel.org>; Fri, 28 Apr 2023 10:59:29 -0700 (PDT)
Received: from letrec.thunk.org ([76.150.80.181])
        (authenticated bits=0)
        (User authenticated as tytso@ATHENA.MIT.EDU)
        by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 33SHxKI7031286
        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
        Fri, 28 Apr 2023 13:59:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
        t=1682704764; bh=DR6/LsFVUoBJktPLFzfP5w67UsHg1xwlACx5/UCmsFc=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To;
        b=NEvxaevxNpIMZOa24NVqVc4pM1Ot5kTyA6WzDW+/U60fLNPAYLinz2jKC01rJirq2
         HAK0HuEkbdX9nKrONsSL1GK1I7lLenznIa0NeHlqZPtnMdcGHxGjpot75Rr/UESPVb
         9lIVdsnrLjc52U048U7cAh6vMXG/a1ujTdC/Spn759KrDSKsztPIbH63pJ7toj6Bqz
         vBsbYGsw2yDuSz/gaRRxz2C/cMScLHGZvnGNQ4B5ZJBbC9L+E5OSExNmI5Hy9rbBpe
         cZLkFMTlTGEP4noiZt4ekSzY9wHjR8P8tke7atZGLS1wkAuWdk10spOBuAi4nAr/L1
         d37VHgzVZ8RuA==
Received: by letrec.thunk.org (Postfix, from userid 15806)
        id 5E7E88C01E0; Fri, 28 Apr 2023 13:59:20 -0400 (EDT)
Date:   Fri, 28 Apr 2023 13:59:20 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Wu Jianyue <wujianyue000@gmail.com>
Cc:     adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: Put inode_operations in inode.c
Message-ID: <ZEwJeMUM3bxTLx4q@mit.edu>
References: <20230428133420.6959-1-wujianyue000@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230428133420.6959-1-wujianyue000@gmail.com>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 28, 2023 at 09:34:20PM +0800, Wu Jianyue wrote:
> inode_operations is more suitable to put in inode.c,
> instead of file.c, so moved to inode.c.

The inode operations structure for directories is in fs/ext4/namei.c;
the inode operations for symlinks is in fs/ext4/symlink.c.  Exactly
where the structure definition is somewhat arbitrary; should it be
where the majority of the functions are defined?  Should it be
associated with the file where operations for that inode type are
located?  Should it be in the file where the structure is used (which
is actually in two files; fs/ext4/namei.c and fs/ext4/inode.c)?

Moving it is just churn and makes things less consistent, so I don't
think it's worth it to take this patch, sorry.

      	   	       	    	 	- Ted