Re: [PATCH 1/2] lib/string_helpers: Introduce strsplit_u32()

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 2022-07-12 4:24 PM, Andy Shevchenko wrote:
> On Tue, Jul 12, 2022 at 03:51:04PM +0200, Cezary Rojewski wrote:
>> On 2022-07-09 10:42 PM, Andy Shevchenko wrote:
> 
> ...
> 
>> I still believe that casting blindly is not the way to go. I did explicitly
>> ask about int vs u32, not int vs unsigned int. Please note that these values
>> are later passed to the IPC handlers, and this changes the context a bit. If
>> hw expects u32, then u32 it shall be.
> 
> What you can do is probably utilize _Generic() which will reduce the code base
> and allow to use the same template for different types.


Hello,

I've spent some time analyzing possible utilization of _Generic() in 
context of get_options() but in my opinion get_range() complicates 
things enough that get_range() and get_option() would basically need a 
copy per type.


If Linux kernel guarantees that sizeof(int), sizeof(unsigned int), 
sizeof(s32) and sizeof(u32) are all equal (given the currently supported 
arch set), then indeed modifying get_options() may not be necessary. 
This plus shamelessly casting (u32 *) to (int *) of course.

What's left to do is the __user helper function. What I have in mind is:

int tokenize_user_input(const char __user *from, size_t count, loff_t 
*ppos, int **tkns)
{
	int *ints, nints;
	char *buf;
	int ret;

	buf = kmalloc(count + 1, GFP_KERNEL);
	if (!buf)
		return -ENOMEM;

	ret = simple_write_to_buffer(buf, count, ppos, from, count);
	if (ret != count) {
		ret = (ret < 0) ? ret : -EIO;
		goto free_buf;
	}

	buf[count] = '\0';

	get_options(buf, 0, &nints);
	if (!nints) {
		ret = -ENOENT;
		goto free_buf;
	}

	ints = kcalloc(nints + 1, sizeof(*ints), GFP_KERNEL);
	if (!ints) {
		ret = -ENOMEM;
		goto free_buf;
	}

	get_options(buf, nints + 1, ints);
	*tkns = ints;
	ret = 0;

free_buf:
	kfree(buf);
	return ret;
}


Usage:
	u32 *tkns;

	ret = tokenize_user_input(from, count, ppos, (int **)&tkns);


as a part of fs/libfs.c not lib/cmdline.c. Is such approach acceptable?



Regards,
Czarek