On Thu, 2021-09-16 at 15:47 -0700, Dan Williams wrote: > On Tue, Aug 31, 2021 at 2:05 AM Vishal Verma <[email protected]> wrote: > > > > Add a man page update describing how daxctl-reconfigure-device(1) can > > be used for persistent reconfiguration of a daxctl device using a > > config file. > > > > Cc: Dan Williams <[email protected]> > > Signed-off-by: Vishal Verma <[email protected]> > > --- > > .../daxctl/daxctl-reconfigure-device.txt | 67 +++++++++++++++++++ > > 1 file changed, 67 insertions(+) > >
[snip] (I've made all the other documentation changes suggested). > > > > + > > +[auto-online dax2] > > +uuid = f36d02ff-1d9f-4fb9-a5b9-8ceb10a00fe3 > > +mode = system-ram > > +online = true > > +movable = false > > One of the tasks I envisioned with persistent configurations was > recalling resize and create device operations. Not saying that needs > to be included now, but I can assume that these reconfiguration steps > are performed in order... Hmm, as I ask that I realize it may depend > on device arrival. Ok, assuming the devices have all arrived by the > time this runs is there a guarantee that these are processed in order? Hm, I don't quite follow what you mean by processing in order. The logic here is that there are two 'classes' of config items in this section - 'identification' and 'action' The uuid is the only identification item - it is used to match the right device. The others - 'action' items, dictate what will be done to that device. The order here doesn't (shouldn't?) matter as these just set the param.foo fields in daxctl/device.c, and let do_reconfig() run wild with them, just as if the params were specified on the command line.
