Brice Goglin, le Mon 09 Nov 2009 15:18:11 +0100, a écrit : > I don't think we need SET_CPUBIND since (from what I understand) it > would be equivalent to SET_PROC_CPUBIND | SET_THREAD_CPUBIND.
Being able to set oneself's cpuset is not the same as being able to set the cpuset of other processes or other threads. We should also probably expose whether strict binding is available and whether whole processes and single threads can be bound. In a word, I believe we should just expose which exact parts of the binding API will never return ENOSYS. That would make it a lot easier to comprehend and much more straightforward to use it even though the interface is very powerful and can thus lead to a lot of binding possibilities. If an application has requirements A, B and C and would be even happier if D and E were available, it can prepare arguments for A, B and C, and if D and E are announced as being available, add arguments for them, and then call the function. That saves trying with D and E, or only with D, or only with E, and eventually fallback to not using either.. > We'd have to keep in mind that 32bits in this flag bitmask is small > (we'll likely need many other flags in the future, for instance > IODEVICE_DISCOVERY, SET/GET_MEMBIND, SET/GET_RANGE_MEMBIND). That's probably a hint that we should find another way :) How about a function that returns a structure filled with one long per feature (detection, thread bind, memory bind, etc.), part of hwloc_topology_t? That way we can extend it at will. Samuel
