qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC] Fixing the error failure


From: Luiz Capitulino
Subject: [Qemu-devel] [RFC] Fixing the error failure
Date: Wed, 20 Jun 2012 14:48:38 -0300

Yet another thread fork.

After talking with Daniel and Markus about QMP errors (which is not just about
QMP, as this affects QEMU as whole), I've put together the proposal below.

I'll discuss three points. First, the error format and classes. Second, the
internal API and third compatibility.

Don't be afraid about the length of this email, only the first section is long
but it mostly contains error classes listings.

1. Error format and classes

We can keep the same error format we have today, which is:

 { "error": { "class": json-string,
              "data": json-object,
              "desc": json-string }, "id": json-value }

  where 'data', 'desc' and 'id' are optional fields.

However, we'd change how we use 'desc' and our error classes. 'desc' would
become a string which is filled by a printf-like function (see section 2) and
we'd replace all error classes we have today by the following ones:

  o ParameterError: any error which involves a bad parameter. Replaces
    InvalidParameter, InvalidParameterCombination, InvalidParameterType,
    InvalidParameterValue, MissingParameter

  o SystemError: syscall or library errors. Replaces BufferOverrun,
    IOError, OpenFileFailed, PermissionDenied, TooManyFiles,
    SockConnectInprogress, SockConnectFailed, SockListenFailed,
    SockBindFailed, SockCreateFailed.

    This error can include an optional 'os-error' field in the 'data'
    member (see section 2).

  o QEMUError: errors that are internal to QEMU, like AmbiguousPath,
    BadBusForDevice, BusNoHotplug, BusNotFound, CommandDisabled,
    CommandNotFound, DuplicateId, FeatureDisabled, JSONParseError,
    JSONParsing, KVMMissingCap, MigrationActive, MigrationNotSupported,
    MigrationExpected, NoBusForDevice, NotSupported, PropertyValueBad,
    PropertyValueInUse, PropertyValueNotFound, PropertyValueNotPowerOf2,
    PropertyValueOutOfRange, ResetRequired, SetPasswdFailed, Unsupported,
    VirtFSFeatureBlocksMigration, VNCServerFailed

  o UndefinedError: the same it's today, undefined :)

Now, there are two important points to be observed:

 - We check for DeviceEncrypted in hmp.c and fetch its parameters. This
   probably indicates that we might want to create specialized classes
   when necessary

 - I don't know where to put all the DeviceFoo errors, but they probably fit
   in QEMUError or a new class like DeviceError

2. Internal API

This is very straightforward:

 o error_set_deprecated();

   Current error_set(), case we keep it for compatibility (see section 3).

 o error_set(ErrorClass err_class, const char *fmt, ...);

   Main function, sets the error classes and allow for a free human-readable
   error message.

 o error_set_sys_fmt(int err_no, const char *fmt, ...);
 o error_set_sys(int err_no);

   Helpers for setting SystemError errors. error_set_sys() gets the 'desc'
   string from strerror().

3. Compatibility

We have two options here:

 1. Maintain the current errors and implement the new way only for new
    commands (includes commands merged for 1.2).

      Pros: maintains compatibility and won't require any code churn
      Cons: we'll have two different errors schemas in use at the same
            time and will be carrying garbage forward

 2. Do a full conversion to the new way.

      Pros: we drop bad code and avoid pollution (good for Rio+20)
      Cons: possibly breaks compatibility and will require a lot of code
            churn up front



reply via email to

[Prev in Thread] Current Thread [Next in Thread]