On Sat, Apr 27, 2019 at 08:29:34PM -0700, Yury Norov wrote:
> bitmap_parse() is ineffective and full of opaque variables and opencoded
> parts. It leads to hard understanding of it. This rework includes:
> - remove bitmap_shift_left() call from the cycle. Now it makes the
> complexity of the algorithm as O(nbits^2). In the suggested approach
> the input string is parsed in reverse direction, so no shifts needed;
> - relax requirement on a single comma and no white spaces between chunks.
> It is considered useful in scripting, and it aligns with
> bitmap_parselist();
> - split bitmap_parse() to small readable helpers;
> - make an explicit calculation of the end of input line at the
> beginning, so users of the bitmap_parse() won't bother doing this.
> +static inline bool in_str(const char *start, const char *ptr)
> +{
> + return start <= ptr;
> +}
> +
I don't see how it's better than explicit use. Moreover, explicit use shows the
exact condition in-line. Even by used characters it's longer.
> +static const char *bitmap_get_hex32_rev(const char *start,
> + const char *end, u32 *num)
In kernel few functions to work with hex u32 named foo_x32(). I would rather
use that. Besides, we spell "reverse" in full.
> +{
> + u32 ret = 0;
> + int c, i;
> +
> + if (hex_to_bin(*end) < 0)
> + return ERR_PTR(-EINVAL);
> +
> + for (i = 0; i < 32; i += 4) {
> + c = hex_to_bin(*end--);
> + if (c < 0)
Perhaps we may need similar patch for hex_to_bin() as in the commit
9888a588ea96 ("lib/hexdump.c: return -EINVAL in case of error in hex2bin()")
> + return ERR_PTR(-EINVAL);
> +
> + ret |= c << i;
> +
> + if (!in_str(start, end) || __end_of_region(*end))
> + goto out;
> + }
> +
> + if (hex_to_bin(*end) >= 0)
> + return ERR_PTR(-EOVERFLOW);
> +out:
> + *num = ret;
> + return end;
> +}
--
With Best Regards,
Andy Shevchenko
