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.
+ +int virProcessInfoGetAffinity(pid_t pid ATTRIBUTE_UNUSED, + virBitmapPtr *map, + int maxcpu) +{ + *map = virBitmapNew(maxcpu); + if (!map) { + virReportOOMError(); + return -1; + } + virBitmapSetAll(*map); + + return 0; +} + #else /* HAVE_SCHED_GETAFFINITY */
int virProcessInfoSetAffinity(pid_t pid ATTRIBUTE_UNUSED,
Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Roman Bogorodskiy