On Mon, 26 Feb 2024 11:35:17 -0600 John Groves <John@xxxxxxxxxx> wrote: > On 24/02/26 12:48PM, Jonathan Cameron wrote: > > On Fri, 23 Feb 2024 11:41:52 -0600 > > John Groves <John@xxxxxxxxxx> wrote: > > > > > Add the famfs_internal.h include file. This contains internal data > > > structures such as the per-file metadata structure (famfs_file_meta) > > > and extent formats. > > > > > > Signed-off-by: John Groves <john@xxxxxxxxxx> > > Hi John, > > > > Build this up as you add the definitions in later patches. > > > > Separate header patches just make people jump back and forth when trying > > to review. Obviously more work to build this stuff up cleanly but > > it's worth doing to save review time. > > > > Ohhhhkaaaaay. I think you're right, just not looking forward to > all that rebasing. :) Patch mangling is half the fun of upstream development :) > > > Generally I'd plumb up Kconfig and Makefile a the beginning as it means > > that the set is bisectable and we can check the logic of building each stage. > > That is harder to do but tends to bring benefits in forcing clear step > > wise approach on a patch set. Feel free to ignore this one though as it > > can slow things down. > > I'm not sure that's practical. A file system needs a bunch of different > kinds of operations > - super_operations > - fs_context_operations > - inode_operations > - file_operations > - dax holder_operations, iomap_ops > - etc. > > Will think about the dependency graph of these entities, but I'm not sure > it's tractable... Sure. There's a difference though between doing something useful (or even successfully loading) and being able to build it at intermediate steps. I'm only looking for buildability. If not possible, even with a few stubs, empty ops structures etc then fair enough. Jonathan
