On 2013年01月03日 08:01, Eric Blake wrote:
On 01/02/2013 07:37 AM, Osier Yang wrote:
"virGetDeviceID" could be used across the sources, but it doesn't
relate with this series, and could be done later.
* src/util/virutil.h: (Declare virGetDeviceID, and
vir{Get,Set}DeviceUnprivSGIO)
* src/util/virutil.c: (Implement virGetDeviceID and
vir{Get,Set}DeviceUnprivSGIO)
* src/libvirt_private.syms: Export private symbols of upper helpers
---
src/libvirt_private.syms | 3 +
src/util/virutil.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++
src/util/virutil.h | 11 ++++
3 files changed, 154 insertions(+), 0 deletions(-)
ACK.
+int
+virSetDeviceUnprivSGIO(const char *path,
+ const char *sysfs_dir,
+ int unpriv_sgio)
+{
+ char *sysfs_path = NULL;
+ char *val = NULL;
+ int ret = -1;
+ int rc;
+
+ if (!(sysfs_path = virGetUnprivSGIOSysfsPath(path, sysfs_dir)))
+ return -1;
+
+ if (!virFileExists(sysfs_path)) {
+ virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+ _("unpriv_sgio is not supported by this kernel"));
+ goto cleanup;
If 'unpriv_sgio' is 0 here, does it make the logic in any later patches
easier to return success in that case (you are setting things to the
default)? But I'm okay with keeping it as a failure.
The "unpriv_sgio == 0" could be requested explicitly by user (not only
the from the default), and in this case I'd think an error is better.
Otherwise I could see one will raise bug like "sgio='filtered'
succeeded, but sgio='unfiltered' failed" unless we document it
somewhere.
Regards,
Osier
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
