On Mon, Jun 23, 2025 at 09:18:33AM -0700, Linus Torvalds wrote:
> I'm not objecting to the patch, and I don't really even have a
> solution: many of the existing cases actually do need the more
> complicated vfs_parse_fs_string() interface because they don't want
> that simple 'strlen()' for size.
I don't know... 7 callers with explicit strlen():
drivers/gpu/drm/i915/gem/i915_gemfs.c:16: return vfs_parse_fs_string(fc, key, val, strlen(val));
drivers/gpu/drm/v3d/v3d_gemfs.c:12: return vfs_parse_fs_string(fc, key, val, strlen(val));
fs/namespace.c:1284: ret = vfs_parse_fs_string(fc, "source",
fs/namespace.c:3799: err = vfs_parse_fs_string(fc, "subtype",
fs/namespace.c:3802: err = vfs_parse_fs_string(fc, "source", name, strlen(name));
fs/nfs/fs_context.c:1230: ret = vfs_parse_fs_string(fc, "context",
kernel/trace/trace.c:10280: ret = vfs_parse_fs_string(fc, "source",
3 callers that could as well use strlen(), except that some of them need
to cope with NULL (using 0 for length in that case):
fs/fs_context.c:230: ret = vfs_parse_fs_string(fc, key, value, v_len);
fs/nfs/namespace.c:293: ret = vfs_parse_fs_string(fc, "source", p, buffer + 4096 - p);
fs/smb/client/fs_context.c:785: ret = vfs_parse_fs_string(fc, key, value, len);
1 caller that really does need len < strlen(s):
fs/afs/mntpt.c:140: ret = vfs_parse_fs_string(fc, "source", content, size - 1);
> I just feel that at a minimum you shouldn't implement add_param()
> twice, because some other users *would* want to do that.
>
> So I wish you had made that a real helper - which would obviously then
> also force a naming change ("fs_context_add_param()".
May the bikeshedding commence ;-)
> Or maybe even go further and some helper to doi that
> "fs_context_for_mount()" _with_ a list of param's to be added?
Vararg, presumably?
> I do think that could be done later (separately), but wanted to just
> mention this because I reacted to this patch.
