Re: [PATCH V4 1/2] daxctl: Add support for famfs mode

["John Groves" <jgroves@fastmail.com>]

On Tue, Apr 28, 2026, at 2:14 PM, Ira Weiny wrote:
> Alison Schofield wrote:
> > On Sun, Apr 26, 2026 at 06:56:46PM -0500, John Groves wrote:
> > > Maybe I'm overcomplicating things (it's one of the things I do), 
> > > but I'm still struggling through how to address all these issues. 
> > > Some comments inline.
> > 
> > 
> > Jumping to the part you commented on, which I think was the biggie:
> > 
> > > 
> > > On 26/02/26 06:00PM, Alison Schofield wrote:
> > > > On Sun, Jan 18, 2026 at 10:36:38PM +0000, John Groves wrote:
> > > > > From: John Groves <John@Groves.net>
> > > > > 
> > > > > Putting a daxdev in famfs mode means binding it to fsdev_dax.ko
> > > > > (drivers/dax/fsdev.c). Finding a daxdev bound to fsdev_dax means
> > > > > it is in famfs mode.
> > > > > 
> > > > > The test is added to the destructive test suite since it
> > > > > modifies device modes.
> > > > 
> > > > Make it clear that it is added in a separate patch. (and assume you
> > > > can drop the destructive part too.)
> > > > 
> > > > > 
> > > > > With devdax, famfs, and system-ram modes, the previous logic that assumed
> > > > > 'not in mode X means in mode Y' needed to get slightly more complicated
> > > > > 
> > > > > Add explicit mode detection functions:
> > > > > - daxctl_dev_is_famfs_mode(): check if bound to fsdev_dax driver
> > > > > - daxctl_dev_is_devdax_mode(): check if bound to device_dax driver
> > > > 
> > > > 
> > > > The precedence check (ram->famfs->devdax->unknown) now happens in multiple
> > > > places. How about adding a daxctl_dev_get_mode() helper to centralize that.
> > > > It could be private for now, unless you expect external users to need it.
> > > > 
> > > > daxctl_dev_is_famfs_mode() and _is_devdax_mode() are nearly identical aside
> > > > from the module name. Refactoring the shared part into a single helper will
> > > > also make it easier to add a daxctl_dev_get_mode() without duplicating the
> > > > precedence logic.
> > > > 
> > > > > 
> > > > > Fix mode transition logic in device.c:
> > > > > - disable_devdax_device(): verify device is actually in devdax mode
> > > > > - disable_famfs_device(): verify device is actually in famfs mode
> > > > > - All reconfig_mode_*() functions now explicitly check each mode
> > > > > - Handle unknown mode with error instead of wrong assumption
> > > > 
> > > > Wondering about 'Fix' mode transition logic. Was prior logic broken and
> > > > should any of these changes be in a precursor patch that is a 'fix'.
> > > > 
> > > > 
> > > > > 
> > > > > Modify json.c to show 'unknown' if device is not in a recognized mode.
> > > > 
> > > > I think this means disabled devices will always look unknown even when
> > > > the intended mode is devdax or famfs, but disabled. This seems to
> > > > change the meaning of mode from 'configured' to 'active' personality.
> > > > Can you detect the configured mode even when disabled?
> > > > Perhaps a man page change about this new behavior?
> > > 
> > > Good point; before famfs mode there were just 2 modes, and 
> > > not-system-ram == devdax mode is the current standard, even if no driver 
> > > is bound. At some level that's a conflation, but I'll revise and stick 
> > > with that unless you have a better idea.
> > > 
> > > Is that how you want it? No driver == devdax mode?
> > > 
> > > Any thoughts?
> > > 
> > 
> > I do think we need to introduce "unknown" rather than keep reporting
> > devdax for all non-system-ram devices. With famfs added, that old
> > "not system-ram == devdax" shortcut just isn’t true anymore, and in the
> > unbound case we really don’t know if it’s devdax or famfs. I’d rather say
> > "unknown" than guess wrong.
> 
> While I like the explicit nature of 'unknown' we are unfortunately past
> that point now.
> 
> Current users expect a new device to come up as devdax.  I think a new
> specifier needs to be added to bring a device up as famfs.  Because this
> is the new way of doing things it may be that famfs needs to be specified
> explicitly somewhere.  I'm not quite sure where right off.
> 
> But the current behavior needs to be maintained despite it being 'wrong'
> or a 'lie'...  It is just the way it was.
> 
> Ira

I think for famfs it's easier than that. The famfs tools already put it in famfs
mode when needed. I don't think it ever needs to have a sticky default
to anything but devdax.

The following famfs operations already check and change the mode 
if necessary:

- famfs mount
- mkfs.famfs
- famfs fsck /dev/dax0.0 

So I don't see any problem with preserving the existing quirkiness.

I'll get a patch v5 out asap that continues to mark unbound daxdev as
'devdax' and also 'disabled'. No change to system-ram mode. 

I think this might be all we need...

<snip>

John