system-ram devices look same as devdax

[kilobyte]

A namespace configured for -m devdax looks like:

[~]# ndctl list
[
  {
    "dev":"namespace1.0",
    "mode":"devdax",
    "map":"dev",
    "size":1054867456,
    "uuid":"445664fa-8def-4dfc-85aa-aa7ded8b4f54",
    "chardev":"dax1.0",
    "align":2097152
  },

Then, after [~]# daxctl reconfigure-device -m system-ram dax1.0

[~]# ndctl list
[
  {
    "dev":"namespace1.0",
    "mode":"devdax",
    "map":"dev",
    "size":1054867456,
    "uuid":"445664fa-8def-4dfc-85aa-aa7ded8b4f54",
    "chardev":"dax1.0",
    "align":2097152
  },

which is exactly the same.

As a system-ram device behaves nothing like devdax from an user's point of view, why would ndctl unify them? We already have four distinct modes: raw, sector, fsdax and devdax, in addition to modes configurable by ipmctl (AppDirect vs memory mode). Having devdax work completely differently based on some setting adds confusion to the user — it would be better to avoid inventing yet another layer of modes.

The internal kernel↔ndctl interface is different, but that's an implementation detail that could be abstracted away.

(Submitting this issue after a discussion with @janekmi.)

[djbw]

Hmm, yes, there is a bug there, but the mode data is correct. ndctl manages attaching a device-dax instance to a namespace. That device-dax instance can then be bound to either the "device_dax", or the "kmem" driver (see /sys/bus/dax/drivers). When bound to "device_dax" the character device is attached as a child of the device-dax instance, when bound to "kmem" it's added as system-ram.

If you run "ndctl list -X" you'll see ndctl dig into the next level of detail.

# ndctl list -X
[
  {
    "dev":"namespace0.0",
    "mode":"devdax",
    "map":"dev",
    "size":4225761280,
    "uuid":"110e25d4-f8d9-460e-a735-0d786c11f1e2",
    "daxregion":{
      "id":0,
      "size":4225761280,
      "align":2097152,
      "devices":[
        {
          "chardev":"dax0.0",
          "size":4225761280,
          "target_node":2,
          "mode":"system-ram",
          "movable":true
        }
      ]
    },
    "align":2097152
  }
]

However, as you can see it will still emit "chardev" fields which is incorrect.

So I'm thinking your second example should be something like:

# ndctl list
[
  {
    "dev":"namespace1.0",
    "mode":"devdax",
    "size":1054867456,
    "uuid":"445664fa-8def-4dfc-85aa-aa7ded8b4f54",
    "system-ram":true,
  },

In other words the chardev is not attached, the location of the struct page is not configurable (drop the "map" property), the alignment does not matter anymore, and adding system-ram creates a family of memory-block devices just emit a boolean flag to indicate "system-ram". The -X output needs some similar fixups.

Would that address the concern?

[kilobyte]

Sounds good to me.

While I believe it should be a whole distinct mode, that train has probably sailed long ago.

Thanks for pointing out ndctl list -X — we need to cope with old ndctls thus your suggestion allows avoiding requiring and parsing daxctl's output as well.