[PATCH 1/2] lib/string_helpers: Introduce strsplit_u32()
Cezary Rojewski
cezary.rojewski at intel.com
Tue Aug 9 11:55:40 CEST 2022
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
More information about the Alsa-devel
mailing list