On Wed, 10/31 15:51, Markus Armbruster wrote:
> Fam Zheng writes:
>
> > Use error_report for situations that affect user operation (i.e. we're
> > actually returning error), and warn_report/warn_report_err when some
> > less critical error happened but the user operation can still carry on.
> >
On 10/31/18 11:05 AM, Philippe Mathieu-Daudé wrote:
On 31/10/18 15:57, Eric Blake wrote:
On 10/31/18 12:39 AM, Fam Zheng wrote:
...
- fprintf(stderr, "%s: stat failed: %s\n",
- fname, strerror(errno));
+ error_setg(errp, "%s: stat failed: %s", fname,
strerror(errno));
On 31/10/18 15:57, Eric Blake wrote:
On 10/31/18 12:39 AM, Fam Zheng wrote:
...
- fprintf(stderr, "%s: stat failed: %s\n",
- fname, strerror(errno));
+ error_setg(errp, "%s: stat failed: %s", fname, strerror(errno));
return -errno;
error_setg_errno() is nice
On 10/31/18 12:39 AM, Fam Zheng wrote:
Use error_report for situations that affect user operation (i.e. we're
actually returning error), and warn_report/warn_report_err when some
less critical error happened but the user operation can still carry on.
For raw_normalize_devicepath, add Error para
Fam Zheng writes:
> Use error_report for situations that affect user operation (i.e. we're
> actually returning error), and warn_report/warn_report_err when some
> less critical error happened but the user operation can still carry on.
>
> For raw_normalize_devicepath, add Error parameter to pro
Use error_report for situations that affect user operation (i.e. we're
actually returning error), and warn_report/warn_report_err when some
less critical error happened but the user operation can still carry on.
For raw_normalize_devicepath, add Error parameter to propagate to
its callers.
Sugge
