linux-kernel - Re: [RFC PATCH 08/20] famfs: Add famfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <agvghv2lask3iazxtycynwkdydrxqula3pwbrusvwn3e2fz6jd@nrmpnbamp6f7>
Date: Tue, 27 Feb 2024 19:06:09 -0600
From: John Groves <John@...ves.net>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: John Groves <jgroves@...ron.com>, Jonathan Corbet <corbet@....net>, 
	Dan Williams <dan.j.williams@...el.com>, Vishal Verma <vishal.l.verma@...el.com>, 
	Dave Jiang <dave.jiang@...el.com>, Alexander Viro <viro@...iv.linux.org.uk>, 
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, Matthew Wilcox <willy@...radead.org>, 
	linux-cxl@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, nvdimm@...ts.linux.dev, john@...alactic.com, 
	Dave Chinner <david@...morbit.com>, Christoph Hellwig <hch@...radead.org>, 
	dave.hansen@...ux.intel.com, gregory.price@...verge.com
Subject: Re: [RFC PATCH 08/20] famfs: Add famfs_internal.h

On 24/02/27 10:28AM, Jonathan Cameron wrote:
> On Mon, 26 Feb 2024 11:35:17 -0600
> John Groves <John@...ves.net> wrote:
> 
> > On 24/02/26 12:48PM, Jonathan Cameron wrote:
> > > On Fri, 23 Feb 2024 11:41:52 -0600
> > > John Groves <John@...ves.net> 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@...ves.net>  
> > > 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