From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta1.migadu.com (out-182.mta1.migadu.com [95.215.58.182]) (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 4108D13AD8 for ; Thu, 25 Jul 2024 03:01:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721876514; cv=none; b=g+VxSsY9RuEue7iRWAP051JoojmfZeMrW3K0F0t4tiBq29U4d4r13vu9e/wg7gRTABFti0nn3c2/xFwfFl6FI2Q8ogLO2i47/xYOXT0CDBkOaGexLmkeUWGVSnhcX64nAG53V14iQ/2jWTwBku3ZR88T1zHF/kHuMAQ5D8ihDic= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721876514; c=relaxed/simple; bh=49jcBefj5FcT3M9x20xUQPUdsQZFD9U6hguK29l+JiI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lYvtY33wxtv6EVNOvoBGshF8mujfQQyLr1If5mm9Q79qVczpKmNBVyhqXKBouP5k49JTXDQhsUhmNhtr4r7njv2keb036ZUp5f+mRZ9Lu+rslO3Bsyb/zCBVoVfekD4BLDKElG8JUZ+8m7E8NSN91lxbavWYrulxbOhtQcN2F/E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=t0bnRmik; arc=none smtp.client-ip=95.215.58.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="t0bnRmik" Message-ID: <895360e3-97bb-4188-a91d-eaca3302bd43@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1721876510; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dinahWWNWKVgxUr2QQ8r5vtDMN47K5jpbrU4x04fZmQ=; b=t0bnRmiksgMcuV2n4/X74UTpJITvS5MrnJV4M93S6NWIOs2XsMr+6Kz8W7etk9BqNLgiLm WyW+SnXPb9G/KKg4743QNI4cw/8+OwX72AkIF3GAqZwoNi6QNrEMZbnhD9k/VEF+m8nY7q VR/2e2/7phjKq6pM1GTTV0CvBfSEfNI= Date: Thu, 25 Jul 2024 11:01:33 +0800 Precedence: bulk X-Mailing-List: linux-modules@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 1/4] module: Add module_subinit{_noexit} and module_subeixt helper macros To: Christoph Hellwig Cc: Arnd Bergmann , Luis Chamberlain , Chris Mason , Josef Bacik , David Sterba , tytso@mit.edu, Andreas Dilger , Jaegeuk Kim , Chao Yu , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Youling Tang References: <20240723083239.41533-1-youling.tang@linux.dev> <20240723083239.41533-2-youling.tang@linux.dev> <0a63dfd1-ead3-4db3-a38c-2bc1db65f354@linux.dev> Content-Language: en-US, en-AU X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Youling Tang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 24/07/2024 23:43, Christoph Hellwig wrote: > On Wed, Jul 24, 2024 at 09:57:05AM +0800, Youling Tang wrote: >> module_init(initfn)/module_exit(exitfn) has two definitions (via MODULE): >> - buindin: uses do_initcalls() to iterate over the contents of the specified >>   section and executes all initfn functions in the section in the order in >>   which they are stored (exitfn is not required). >> >> - ko: run do_init_module(mod)->do_one_initcall(mod->init) to execute initfn >>   of the specified module. >> >> If we change module_subinit to something like this, not called in >> module_init, >> Not only do we want to ensure that exit is executed in reverse order of >> init, but we also want to ensure the order of init. > Yes. > >> This does not guarantee the order in which init will be executed (although >> the init/exit order will remain the same) > Hmm, so the normal built-in initcalls depend on the link order, but when > they are in the same file, the compiler can reorder them before we even > get to the linker. > > I wonder what a good syntax would be to still avoid the boilerplate > code. We'd probably need one macro to actually define the init/exit > table in a single statement so that it can't be reordered, but that > would lose the ability to actually declare the module subinit/exit > handlers in multiple files, which really is the biggest win of this > scheme as it allows to keep the functions static instead of exposing > them to other compilation units. > > And in fact even in your three converted file systems, most > subinit/exit handler are in separate files, so maybe instead > enforcing that there is just one per file and slightly refactoring > the code so that this is the case might be the best option? - It doesn't feel good to have only one subinit/exit in a file.   Assuming that there is only one file in each file, how do we   ensure that the files are linked in order?(Is it sorted by *.o   in the Makefile?) - Even if the order of each init is linked correctly, then the   runtime will be iterated through the .subinitcall.init section,   which executes each initfn in sequence (similar to do_initcalls),   which means that no other code can be inserted between each subinit. If module_subinit is called in module_init, other code can be inserted between subinit, similar to the following: ``` static int __init init_example(void) {     module_subinit(inita, exita);     otherthing...     module_subinit(initb, exitb);     return 0; } module_init(init_example); ``` IMHO, module_subinit() might be better called in module_init(). Thanks, Youling.