On Tue, 14 May 2019 02:12:35 -0400 Yan Zhao <yan.y.zhao@intel.com> wrote:
On Mon, May 13, 2019 at 09:28:04PM +0800, Erik Skultety wrote:
In case of libvirt checking the compatibility, it won't matter how good the error message in the kernel log is and regardless of how many error states you want to handle, libvirt's only limited to errno here, since we're going to do plain read/write, so our internal error message returned to the user is only going to contain what the errno says - okay, of course we can (and we DO) provide libvirt specific string, further specifying the error but like I mentioned, depending on how many error cases we want to distinguish this may be hard for anyone to figure out solely on the error code, as apps will most probably not parse the logs.
Regards, Erik hi Erik do you mean you are agreeing on defining common errors and only returning errno?
e.g. #define ENOMIGRATION 140 /* device not supporting migration */ #define EUNATCH 49 /* software version not match */ #define EHWNM 142 /* hardware not matching*/
Defining custom error codes is probably not such a good idea... can we match to common error codes instead? Do we have a good idea about common error categories, anyway? (Btw: does libvirt do a generic error-to-description translation, or does it match to the context? I.e., can libvirt translate well-defined error codes to a useful message for a specific case?)