---- "Daniel P. Berrange" <[EMAIL PROTECTED]> wrote: 
> On Wed, Feb 20, 2008 at 03:53:46PM +0000, Ian Jackson wrote:
> Content-Description: message body text
> > bdrv_flush is declared to return void, but this is wrong because it
> > means that the implementations have nowhere to report their errors.
> > Indeed, the implementations generally ignore errors.
> > 
> > This patch corrects this by making it return int (implicitly, either 0
> > or -errno, as for other similar functions).  All of the
> > implementations and callers are adjusted too.
> > 
> > 
> > While looking at this I was surprised to see this:
> > 
> >     static void scsi_write_complete(void * opaque, int ret)
> >     ...
> >     if (ret) {
> >         fprintf(stderr, "scsi-disc: IO write error\n");
> >         exit(1);
> >     }
> > 
> > Surely that is overkill ?
> 
> Yes, any i/o errors I'd expect to be propagated back up to the guest
> OS as the most appropriate IDE / SCSI error code.
> 
> > Also, in block-raw-posix.c, raw_pwrite et al seem to return -1 on
> > error (the return value from write) whereas the other block read/write
> > methods return errno values.  This is a mistake, surely ?  -1 would be
> > -EPERM.  If any of the callers did anything with these return values
> > you'd get incorrect error indications.
> > 
> > 
> > Finally, it would perhaps be best if the block device emulators wrote
> > to the qemu console to complain if they give write errors.  Otherwise
> > the errno value and other important information will be lost, which
> > makes debugging hard.
> 
> If by 'qemu console' you mean stderr, then fine, but please don't
> spew log messages to the  monitor console, because that'll make it
> very hard to interact with reliably from management tools. 

Would it make sense to have a log messages screen associated with
the monitor (like Ctrl-Alt-7) to deal with those sorts of things?

Ben


Reply via email to