Re: [Qemu-devel] [PATCH v4 24/29] Introduce signed range.

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jun 10, 2014 at 02:51:49PM +0800, Hu Tao wrote:
> On Mon, Jun 09, 2014 at 01:59:04PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 09, 2014 at 11:42:14AM +0100, Peter Maydell wrote:
> > > On 9 June 2014 11:25, Hu Tao <hutao@cn.fujitsu.com> wrote:
> > > > Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
> > > > ---
> > > >  include/qemu/range.h | 124 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 124 insertions(+)
> > > >
> > > > diff --git a/include/qemu/range.h b/include/qemu/range.h
> > > > index aae9720..8879f8a 100644
> > > > --- a/include/qemu/range.h
> > > > +++ b/include/qemu/range.h
> > > > @@ -3,6 +3,7 @@
> > > >
> > > >  #include <inttypes.h>
> > > >  #include <qemu/typedefs.h>
> > > > +#include "qemu/queue.h"
> > > >
> > > >  /*
> > > >   * Operations on 64 bit address ranges.
> > > > @@ -60,4 +61,127 @@ static inline int ranges_overlap(uint64_t first1, uint64_t len1,
> > > >      return !(last2 < first1 || last1 < first2);
> > > >  }
> > > >
> > > > +typedef struct SignedRangeList SignedRangeList;
> > > > +
> > > > +typedef struct SignedRange {
> > > > +    int64_t start;
> > > > +    int64_t length;
> > > > +
> > > > +    QTAILQ_ENTRY(SignedRange) entry;
> > > > +} SignedRange;
> > > > +
> > > > +QTAILQ_HEAD(SignedRangeList, SignedRange);
> > > 
> > > This seems to be missing documentation about what the
> > > semantics are and why we need it as well as the standard
> > > Range. For instance, what does a SignedRange with a
> > > negative length mean?
> > > 
> > > thanks
> > > -- PMM
> > 
> > 
> > Yes I also don't care for list macros being mixed in with structure.
> > 
> > Also, numa surely uses positive numbers? why do you want
> > signed values?
> 
> It's not purely for numa but for parsing int list like in string
> input/output visitor.
> 
> Hu

I doubt we need negative ranges anywhere.
Let's stick to the minimum functionality necessary for numa,
this patchset is big as is.
I would be happier if we could drop this patch completely
use existing unsigned range APIs, if you need a list struct
add it within the file that uses it.

Having said that we can clean this up afterwards.

-- 
MST