On Mon, 26 Feb 2024 11:35:17 -0600
John Groves <[email protected]> wrote:
> On 24/02/26 12:48PM, Jonathan Cameron wrote:
> > On Fri, 23 Feb 2024 11:41:52 -0600
> > John Groves <[email protected]> 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 <[email protected]>
> > 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
On 24/02/27 10:28AM, Jonathan Cameron wrote:
> On Mon, 26 Feb 2024 11:35:17 -0600
> John Groves <[email protected]> wrote:
>
> > On 24/02/26 12:48PM, Jonathan Cameron wrote:
> > > On Fri, 23 Feb 2024 11:41:52 -0600
> > > John Groves <[email protected]> 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 <[email protected]>
> > > 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
I'm through at least the first stage of grief on this. By the time we're
through this I'll be able to reconstitute the whole bloody thing from memory,
backwards :D
John