On Fri, Jul 26, 2024 at 07:04:35AM -0700, Christoph Hellwig wrote: > On Fri, Jul 26, 2024 at 04:54:59PM +0800, Youling Tang wrote: > > Based on this patch, we may need to do these things with this > > > > > > 1. Change the order of *.o in the Makefile (the same order as before the > > change) > > While we'll need to be careful, we don't need to match the exact > order. Most of the calls simply create slab caches / mempools and > similar things and the order for those does not matter at all. > > Of course the register_filesytem calls need to be last, and sysfs > registration probably should be second to last, but for the vast > amount of calls the order does not matter as long as it is unwound > in reverse order. > > > 2. We need to define module_subinit through the ifdef MODULE > > distinction, > > Yes. > > > When one of the subinit runs in a module fails, it is difficult > > to rollback execution of subexit. > > By having both section in the same order, you an just walk the > exit section backwards from the offset that failed. Of course that > only matters for the modular case as normal initcalls don't get > unwound when built-in either. > > > 4. The order in which subinit is called is not intuitively known > > (although it can be found in the Makefile). > > Link order through make file is already a well known concept due to > it mattering for built-in code.
All of this sounds overengineered for something that is a simple array and two helpers. The code is not finalized so I'll wait for the next version but specific file order in makefile and linker tricks seems fragile and I'm not sure I want this for btrfs.
