On Fri, Dec 04, 2015 at 09:44:20AM -0500, John Ferlan wrote:
> 
> 
> On 12/04/2015 08:46 AM, Ján Tomko wrote:
> > On Tue, Nov 24, 2015 at 03:57:14PM -0500, John Ferlan wrote:
> >> Similar to the openflags VIR_STORAGE_VOL_OPEN_NOERROR processing, if some
> >> read processing operation fails, check the readflags for the corresponding
> >> error flag being set. If so, rather then causing an error - use VIR_WARN
> >> to flag the error, but return -2 which some callers can use to perform
> >> specific actions.
> >>
> >> Signed-off-by: John Ferlan <jfer...@redhat.com>
> >> ---
> >>  src/storage/storage_backend.c | 107 
> >> +++++++++++++++++++++++++++++++-----------
> >>  src/storage/storage_backend.h |  11 +++++
> >>  2 files changed, 90 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/src/storage/storage_backend.h b/src/storage/storage_backend.h
> >> index aa9008e..e3ff306 100644
> >> --- a/src/storage/storage_backend.h
> >> +++ b/src/storage/storage_backend.h
> >> @@ -179,6 +179,17 @@ enum {
> >>      VIR_STORAGE_VOL_OPEN_DIR     = 1 << 4, /* directories okay */
> >>  };
> >>  
> >> +/* VolReadErrorMode flags
> >> + * If flag is present, then operation won't cause fatal error for
> >> + * specified operation, rather a VIR_WARN will be issued and a -2 returned
> >> + * for function call
> >> + */
> >> +enum {
> >> +    VIR_STORAGE_VOL_SEEK_ERROR    = 1 << 0, /* don't error on (l)seek */
> > 
> >> +    VIR_STORAGE_VOL_READ_ERROR    = 1 << 1, /* don't error on *read */
> > 
> > This is the only flag used in this series.
> > 
> > Also, naming it VIR_STORAGE_VOL_READ_NOERROR or 
> > VIR_STORAGE_VOL_READ_IGNORE_ERROR
> > would make its meaning more obvious.
> > 
> 
> I can rename flags to be:
> 
>    VIR_STORAGE_VOL_xxx_IGNORE_ERROR
> 
> or
> 
>    VIR_STORAGE_VOL_IGNORE_xxx_ERROR
> 
> Do you have a preference on order?
> 

VIR_STORAGE_VOL_READ_xxx for VolReadErrorMode flags, similar to
VIR_STORAGE_VOL_OPEN_xxx for VolOpenCheckMode flags.

> I personally didn't find the *_NOERROR to be that obvious, but I agree
> adding IGNORE at least does make it obvious.
> 
> > ACK with the unused flags dropped.
> 
> Is it really that important to remove the SEEK and FILECON failure
> checks? I added them mainly to be "complete".
> 

Yes, not introducing unused code means there is less code to read when
trying to figure out what the code does.

> Sure having them is overkill; however, it was pointed out the v1 was too
> broad. Keeping them just means a change in the future won't have to add
> them. I'm not sure I see the harm, but I'm ambivalent over having to
> remove them for an ACK.
> 

There is also a chance that there might never be a change that needs
them.

Jan

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to