On 05.11.18 17:48, Eric Blake wrote: > On 11/5/18 9:53 AM, David Hildenbrand wrote: > >>> When I first looked at the ranges stuff in the string input visitor, I >>> felt the urge to clean it up, then sat on my hands until it passed. >>> >>> The rest is reasonable once you understand how it works. The learning >>> curve is less than pleasant, though. >>> >> >> Maybe I'll pick this up again when I have more time to invest. >> >> The general concept >> >> 1. of having an input visitor that is able to parse different types >> (expected by e.g. a property) sounds sane to me. >> >> 2. of having a list of *something*, assuming it is int64_t, and assuming >> it is to be parsed into a list of ranges sounds completely broken to me. >> >> I was not even able to find an example QEMU comand line for 2. Is this >> maybe some very old code that nobody actually uses anymore? (who uses >> list of ranges?) > > I believe that the -numa node,cpus=first-last code is an example use of > a list of ranges. At any rate, tests/test-string-input-visitor.c has > test_visitor_in_intList() to ensure we don't break back-compat with the > existing clients that use ranges, as awkward as they may be. >
Indeed, thanks for the pointer. Ranges should indeed be supported. But maybe we can refactor this ugly "pre parse all uint64_t ranges" thingy. -- Thanks, David / dhildenb
