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 <[email protected]>
> > > > >
> > > > > 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
