Fam Zheng <f...@redhat.com> writes: > v4: Add Max's rev-by in both patches, while fixing the "maxs" typo. > > v3: Address comments: > - Add test for large value; [Berto] > - Fix typos "negative" & "caught"; [Eric, Berto] > - Use "LL" suffix to the upper limit constant. [Berto] > > v2: Check the value range and report an appropriate error. [Berto] > > Now the negative values are silently converted to a huge positive number > because we are doing implicit casting from uint64_t to double. Fix it and add > a > test case (this was once fixed in 7d81c1413c9 but regressed when the block > device option parsing code was changed).
I think PATCH 1's commit message could explain the problem in a bit more detail, and it should mention the changed valid range. Other than that, I had two questions: why cast THROTTLE_VALUE_MAX for printing (in scope for the series), and why parse the settings as integers even though they're really floating-point (probably not in scope).