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

Re: [Xen-devel] [RFC 2/6] rangeset_destroy() refactoring

> -----Original Message-----
> From: Andrii Anisov [mailto:andrii.anisov@xxxxxxxxx]
> Sent: 16 February 2017 16:22
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; andrii_anisov@xxxxxxxx; Andrew
> Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>;
> jbeulich@xxxxxxxx; konrad.wilk@xxxxxxxxxx; sstabellini@xxxxxxxxxx; Tim
> (Xen.org) <tim@xxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>
> Subject: Re: [RFC 2/6] rangeset_destroy() refactoring
> > What use are rangesets if the implementation doesn't control the list/tree?
> How on earth would you implement an allocation function otherwise?
> Just to be on the same page, my understanding of the rangesets is as
> following:
>  - Currently the `struct rangeset` is a list of `ranges`. This list
> head is a `range_list` of `struct rangeset`. Currently `range_list`
> manipulations are not protected by any locks. IMO this is the core
> functionality of the rangeset.
>  - Also there is another list head `rangeset_list` inside `struct
> rangeset`. It is used to link a rangeset to an external list of
> rangesets. This is protected by spinlocks now. IMO this functionality
> is odd to the rangeset itself.

Ok. Thanks for the clarification. Yes, that second list_head does not strictly 
belong inside the rangeset structure itself. I guess it could live in a 
'domain_rangeset' wrapper structure.


> Sincerely,
> Andrii Anisov.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.