On Wed, Mar 05, 2025 at 09:13:32AM +0530, Ritesh Harjani wrote: > Dave Chinner <david@xxxxxxxxxxxxx> writes: > > > On Sat, Mar 01, 2025 at 06:39:57PM +0530, Ritesh Harjani wrote: > >> > Why is having hundreds of tiny single-config-only files > >> > better than having all the configs in a single file that is > >> > easily browsed and searched? > >> > > >> > Honestly, I really don't see any advantage to re-implementing config > >> > sections as a "file per config" object farm. Yes, you can store > >> > information that way, but that doesn't make it an improvement over a > >> > single file... > >> > > >> > All that is needed is for the upstream repository to maintain a > >> > config file with all the config sections defined that people need. > >> > We don't need any new infrastructure to implement a "centralised > >> > configs" feature - all we need is an agreement that upstream will > >> > ship an update-to-date default config file instead of the ancient, > >> > stale example.config/localhost.config files.... ..... > > You haven't explained why we need new infrastructure to do something > > we can already do with the existing infrastructure. What problem are > > you trying to solve that the current infrastructure does not handle? > > > > i.e. we won't need to change the global config file very often once the > > common configs are defined in it; it'll only get modified when > > filesystems add new features that need specific mkfs or mount option > > support to be added, and that's fairly rare. > > > > Hence I still don't understand what new problem multiple config files > > and new infrastructure to support them is supposed to solve... > > > I will try and explain our reasoning here: > > 1. Why have per-fs config file i.e. configs/ext4.config or > configs/xfs.config... ..... > 2. Why then add the infrastructure to create a new common > configs/all-fs.config file during make? ..... These aren't problems that need to be solved. These are "solutions" posed as a questions. Let's look at 1): > Instead of 1 large config file it's easier if we have FS specific > sections in their own .config file. I agree we don't need configs/<fs> > directories for each filesystem. But it's much easier if we have > configs/<fs>.config with the necessary sections defined in it. I disagree with both these "it is easier" assertions. That same argument was made for splitting up MAINTAINERS in the kernel tree, which sees far more concurrent changes than a test config file would in fstests. The "split files are easier to use/maintain" argument wasn't persuasive there, and I don't really see that this is any different. We just aren't going to have a lot of change to common test configs once the initial set is defined and committed... > That > will be easy to maintain by their respective FS maintainers rather than > maintaining all sections defined in 1 large common config file. Again, it is no more difficult to add a new section config for a new btrfs config to a configs/default.config file than it is to add it to configs/default-btrfs.config. The config sections are already namespaced by naming convention (i.e. ["FSTYP"-"config description"]), so the argument that we need to add a config namespace to an already namespaced config setup to make it "easier to manage" isn't convincing - it's a subjective opinion. I'm saying subjective analysis is insufficient justification for a change, because the subjective analysis of the situation done by different people can result in (and often does) completely opposed stances. Both subjective opinions are as valid as each other, so the only way to address the situation is to look at the technical merits of the proposal. The requires all parties to understand the problem that needs to be solved. I still don't know what problem is solved by shipping lots of config files and additional code, build infrastructure and CLI interfaces to address. I'm probably still missing something important, but I'm not going to learn what that might be from subjective opinion statements like "X will be easier if ...." > This is a combined configs/all-fs.config file which need not be > maintained in git version control. It gets generated for our direct > use. This is also needed to run different cross filesystem tests from a > single ./check script. i.e. > > ./check -s ext4_4k -s xfs_4k -g quick > > (otherwise one cannot run ext4_4k and xfs_4k from a single ./check invocation) Well, yes, and therein lies the problem with this approach. Where do custom configs go? Are you proposing that everyone with custom configs will be forced to run or manage fstests in some new, different way? > I don't think this is too much burden for "make" to generate this file. > And it's easier than, for people to use configs/all-fs.config to run > cross filesystem tests (as mentioned above). > > e.g. > 1. "make" will generate configs/all-fs.config > 2. Define your devices.config in configs/devices.config > 3. Then run > (. configs/devices.config; ./check -s ext4_4k -s xfs_4k -g quick) <looks at code providec> Yup, and now this is all ignored and doesn't work because the test machine has a custom config setup in <hostname>.config and that overrides using configs/all-fs.config. That is not ideal. Of course, we could add a "configs/local.configs" file for local configs that get included via the make rule. However, now we need both a per-machine configs/local.config to be exist or be distributed at the fstests source code update time (i.e. before build), as well as also needing an additional static per-machine configs/devices.config to be defined before fstests is run. This is much more convoluted that setting up in configs/<hostname>.config once at machine setup time and almost never having to touch it again. The build time requirement also makes it hard to install packaged fstests (e.g. in a rpm or deb) because now there's a configure and build step needed after package installation... Part of the problem is that you've treated the fstests-provided section definitions as exclusive w.r.t. local custom config definitions. i.e. We can't have both fstest defined sections and custom sections at the same time. This restriction essentially forces anyone with a custom config to have to copy the built config file into their custom config file so that they can run both fstests provided and custom configs in the same test run. That is not ideal. Maybe this is an oversight, but I still don't know what problem you are trying to solve and so I can't make any judgement on whether it is a simple mistake or intended behaviour... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
