1. 09 2月, 2016 4 次提交
    • E
      qapi: Drop unused 'kind' for struct/enum visit · 337283df
      Eric Blake 提交于
      visit_start_struct() and visit_type_enum() had a 'kind' argument
      that was usually set to either the stringized version of the
      corresponding qapi type name, or to NULL (although some clients
      didn't even get that right).  But nothing ever used the argument.
      It's even hard to argue that it would be useful in a debugger,
      as a stack backtrace also tells which type is being visited.
      
      Therefore, drop the 'kind' argument as dead.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <1454075341-13658-22-git-send-email-eblake@redhat.com>
      [Harmless rebase mistake cleaned up]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      337283df
    • E
      qapi: Swap 'name' in visit_* callbacks to match public API · 0b2a0d6b
      Eric Blake 提交于
      As explained in the previous patches, matching argument order of
      'name, &value' to JSON's "name":value makes sense.  However,
      while the last two patches were easy with Coccinelle, I ended up
      doing this one all by hand.  Now all the visitor callbacks match
      the main interface.
      
      The compiler is able to enforce that all clients match the changed
      interface in visitor-impl.h, even where two pointers are being
      swapped, because only one of the two pointers is const (if that
      were not the case, then C's looseness on treating 'char *' like
      'void *' would have made review a bit harder).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <1454075341-13658-21-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      0b2a0d6b
    • E
      qapi: Make all visitors supply uint64 callbacks · f755dea7
      Eric Blake 提交于
      Our qapi visitor contract supports multiple integer visitors,
      but left the type_uint64 visitor as optional (falling back on
      type_int64); which in turn can lead to awkward behavior with
      numbers larger than INT64_MAX (the user has to be aware of
      twos complement, and deal with negatives).
      
      This patch does not address the disparity in handling large
      values as negatives.  It merely moves the fallback from uint64
      to int64 from the visitor core to the visitors, where the issue
      can actually be fixed, by implementing the missing type_uint64()
      callbacks on top of the respective type_int64() callbacks, and
      with a FIXME comment explaining why that's wrong.
      
      With that done, we now have a type_uint64() callback in every
      driver, so we can make it mandatory from the core.  And although
      the type_int64() callback can cover the entire valid range of
      type_uint{8,16,32} on valid user input, using type_uint64() to
      avoid mixed signedness makes more sense.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1454075341-13658-15-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      f755dea7
    • E
      qapi: Prefer type_int64 over type_int in visitors · 4c40314a
      Eric Blake 提交于
      The qapi builtin type 'int' is basically shorthand for the type
      'int64'.  In fact, since no visitor was providing the optional
      type_int64() callback, visit_type_int64() was just always falling
      back to type_int(), cementing the equivalence between the types.
      
      However, some visitors are providing a type_uint64() callback.
      For purposes of code consistency, it is nicer if all visitors
      use the paired type_int64/type_uint64 names rather than the
      mismatched type_int/type_uint64.  So this patch just renames
      the signed int callbacks in place, dropping the type_int()
      callback as redundant, and a later patch will focus on the
      unsigned int callbacks.
      
      Add some FIXMEs to questionable reuse of errp in code touched
      by the rename, while at it (the reuse works as long as the
      callbacks don't modify value when setting an error, but it's not
      a good example to set) - a later patch will then fix those.
      
      No change in functionality here, although further cleanups are
      in the pipeline.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1454075341-13658-14-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      4c40314a
  2. 05 2月, 2016 1 次提交
  3. 21 9月, 2015 2 次提交
  4. 23 6月, 2015 1 次提交
  5. 22 6月, 2015 1 次提交
  6. 28 5月, 2014 1 次提交
  7. 19 12月, 2012 2 次提交
  8. 27 3月, 2012 1 次提交
  9. 21 2月, 2012 1 次提交
  10. 18 11月, 2011 1 次提交
  11. 04 10月, 2011 1 次提交
  12. 21 8月, 2011 1 次提交
  13. 22 7月, 2011 1 次提交