---- "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