On Thu, 2020-12-17 at 11:23 +0000, Joao Martins wrote:
The provisioning flow additions has some questions open about the daxctl
user interface. To summarize:
1) Should we always list mappings, or only list them with a -v option? Or
maybe instead of -v to use instead a new -M option which enables the
listing of mappings?
The reason being that it can get quite verbose with a device picks a lot
of mappings, hence I would imagine this info isn't necessary for the casual
I think hiding them behind a new option is probably best. And then we
can have different verbosity levels turn on or off. The verbosity levels
stuff is implemented in ndctl, but I don't think it is in daxctl yet, so
we can just do the specific option to display mappings for now, and then
revisit verbosity levels in the future if we feel like the number of
options is getting out of hand.
2) Does the '--restore <file.json>' should instead be called it
instead '--device'? I feel the name '--restore' is too tied to one
way of using it when the feature can be used by a tool which wants to manage
Hm, I looked at other commands that take an input file - write labels
just calls it --input, so there might be value in staying consistent
with that. But write-infoblock just uses stdin - so that could be
another option. I'd be fine with either of those.
its own range mappings. Additionally, I was thinking that if one
manually add/fixup ranges more easily that we would add
a --mapping <pgoff>:<start>-<end> sort of syntax. But I suppose this
be added later if its really desired.
Agreed with adding this later if needed.
And with these clarified, I could respin it over. Oh and I'm missing a
mappings test as well.
Sounds good I'll wait to get these in.
It's worth mentioning that kexec will need fixing, as dax_hmem regions
created with HMAT or manually assigned with efi_fake_mem= get lost on
kexec because we do not pass the EFI_MEMMAP conventional memory ranges
to the second kernel (only runtime code/boot services). I have a
RFC patch for x86 efi handling, but should get that conversation started