Re: [daxctl PATCH] daxctl: Opt-in to /sys/bus/dax ABI

[Dan Williams <dan.j.williams@intel.com>]

On Thu, Nov 8, 2018 at 12:57 PM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> Dan Williams <dan.j.williams@intel.com> writes:
>
> > In support of the kernel's conversion of the dax-subsystem from a
> > 'class' to a 'bus', teach the libdaxctl subsystem-layout-specific code
> > to parse the new layout. The kernel changes do not effect the primary
> > ndctl use case of putting namespaces into 'dax' mode since that uses
> > libnvdimm namespace device relative paths, but it does break 'ndctl list
> > -X' and 'daxctl list'. For that reason the kernel provides a
> > dax_pmem_compat driver to support the old layout and give time for
> > userspace components to switch.
> >
> > Installation of the latest libdaxctl package arranges for a daxctl
> > configuration file to be dropped in /etc/modprobe.d. The modprobe
> > configuration blacklists dax_pmem_compat modules and sets the proper
> > alias for the dax_pmem module. The modprobe configuration upgrades the
> > default kernel handling to the /sys/bus/dax scheme.
>
> OK, one other snafu: pmdk also uses the /sys/class/dax path (see
> src/common/file.c).  Since ndctl isn't the only consumer, we'd have to
> coordinate the class->bus switch among all parties.

Yes, the only way I can see to do this is to whack-a-mole convert
/sys/class/dax users over to libdaxctl. At a minimum I need to
disconnect the opt-in from a package upgrade and make it an explicit
command with a man page explaining the details and consequences.

> Is there a way to just keep the class-based paths working alongside the
> bus interface?

Unfortunately, devices can't have a 'class' and 'bus' association at
the same time because they will collide on the 'subsystem'
designation. The subsystem association is 1:1.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm