From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: moduleparam: Route DEFINE_KERNEL_PARAM_OPS get pointer via _Generic Date: Mon, 25 May 2026 20:11:17 +1000 Message-ID: In-Reply-To: <20260521133326.2465264-7-kees@kernel.org> References: <20260521133315.work.845-kees@kernel.org> <20260521133326.2465264-7-kees@kernel.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review This is the key migration enabler. The `_Generic` dispatch: ```c +#define _KERNEL_PARAM_OPS_GET(_get) \ + _Generic((_get), \ + int (*)(char *, const struct kernel_param *): NULL, \ + default: (_get)) ``` When `_get` has the legacy `char *` signature, `_KERNEL_PARAM_OPS_GET` yields NULL (and `_KERNEL_PARAM_OPS_GET_STR` yields the pointer via `default`). When `_get` has the new `seq_buf *` signature, the opposite. If `_get` matches neither signature, the `default` branch still fires but the assignment to the struct field produces a type mismatch compile error. **Minor observation:** The `_Generic` selectors use two explicit types plus `default`. If someone passes a `NULL` literal for `_get`, `_Generic` on a null pointer constant may have implementation-defined behavior across compilers. However, passing NULL for `_get` in these macros is unlikely in practice (you'd just omit `.get`), and the existing uses all pass actual function pointers. **Verdict: Clever and correct approach for the migration period.** --- Generated by Claude Code Patch Reviewer