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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list