On Thu, Mar 19, 2015 at 05:25:28PM -0600, Eric Blake wrote:
On 03/19/2015 05:11 PM, John Ferlan wrote:+int +virCgroupSetCpusetMemoryMigrate(virCgroupPtr group, bool migrate) +{ + return virCgroupSetValueStr(group, + VIR_CGROUP_CONTROLLER_CPUSET, + "cpuset.memory_migrate", + migrate ? "1" : "0"); +}are my eyes deceiving me?... boolean here (1 or 0)No, the kernel really works this way - it takes the human-readable string "1" or "0" rather than the C byte '\1' or '\0', so this is the lowest level in the stack where we convert our convenient bool for everyone above us into the string literal the kernel cgroup interface expects.
Yes, exactly. I could've also used SetValueU64(), but that formats that value which is unnecessary overhead.
+int +virCgroupGetCpusetMemoryMigrate(virCgroupPtr group, bool *migrate) +{ + unsigned long long value = 0; + int ret = virCgroupGetValueU64(group,But we're getting a U64 here? for what's documented as "contains a flag (0 or 1)+ VIR_CGROUP_CONTROLLER_CPUSET, + "cpuset.memory_migrate", + &value); + *migrate = !!value;And here, this is one easy way to turn the kernel's string back into a bool (it might also be possible to read as a string, and then do *str=='1', rather than going through an intermediate integer conversion, but I'm not sure it is worth the micro-optimization).
With one exception. If kernel changes the possible values to something else (let's say they'll add "2" for some special new meaning like "move aggressively"), this code will still work.
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
pgpdamfvbgGhc.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list