On 12/17/12 18:25, Daniel P. Berrange wrote:
On Mon, Dec 17, 2012 at 09:09:52PM +0400, Roman Bogorodskiy wrote:
Daniel P. Berrange wrote:
On Sun, Dec 16, 2012 at 06:47:56PM +0400, Roman Bogorodskiy wrote:
---
src/util/processinfo.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/src/util/processinfo.c b/src/util/processinfo.c
index b1db049..4822bcc 100644
--- a/src/util/processinfo.c
+++ b/src/util/processinfo.c
@@ -168,6 +168,28 @@ realloc:
return 0;
}
+#elif defined(__FreeBSD__)
+
+int virProcessInfoSetAffinity(pid_t pid ATTRIBUTE_UNUSED,
+ virBitmapPtr map ATTRIBUTE_UNUSED)
+{
+ return 0;
+}
Hmm, I'm somewhat loathe to be pretending that this works.
IMHO, we should look at 'map' and if it is all-1s then
we should accept it trivially. If it is not all-1s then
we should raise an error so the user knows their requested
config was not honoured
The reasoning behind this change is, as subject says, provide a stub
while there's no complete implementation available. I've been using
it for a couple of weeks and didn't notice any problems.
Would not it make sense to just throw a warning or not critical error to
user so he knows there's no affinity? I was planning to create a
full-feature implementation of that after I'm done with the networking
support.
Ok, since you're planning on implementing this properly, I'll accept
this patch as is for now
As I said in my review, I don't like this approach even if it's going to
be improved in the future. Until it's approved we should go with Dan's
idea about accepting all-1-map and erroring out on everything else.
I will add that to this patch and push it tomorrow.
Peter
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list