On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote: > Traditionally after a migration operation drmgr has coordinated the device > tree > update with the kernel in userspace via the ugly /proc/ppc64/ofdt interface. > This > can be better done fully in the kernel where support already exists. > Currently, > drmgr makes a faux ibm,suspend-me RTAS call which we intercept in the kernel > so > that we can check VASI state for suspendability. After the LPAR resumes and > returns to drmgr that is followed by the necessary update-nodes and > update-properties RTAS calls which are parsed and communitated back to the > kernel > through /proc/ppc64/ofdt for the device tree update. The drmgr tool should > instead initiate the migration using the already existing > /sysfs/kernel/mobility/migration entry that performs all this work in the > kernel. > > This patch adds a show function to the sysfs "migration" attribute that > returns > 1 to indicate the kernel will perform the device tree update after a migration > operation and that drmgr should initiated the migration through the sysfs > "migration" attribute.
I don't understand why we need this? Can't drmgr just check if /sysfs/kernel/mobility/migration exists, and if so it knows it should use it and that the kernel will handle the whole procedure? cheers _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
