Re: [PATCH ndctl v1 0/8] daxctl: Add device align and range mapping allocation

["Verma, Vishal L" <vishal.l.verma@intel.com>]

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
> daxctl listing.

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 specific
> 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 wants to
> manually add/fixup ranges more easily that we would add
> a --mapping <pgoff>:<start>-<end> sort of syntax. But I suppose this could
> 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
> after holidays.
> 
> 	Joao

_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org