On 12/19/25 10:59 AM, Marco Elver wrote:
On Fri, 19 Dec 2025 at 19:39, 'Bart Van Assche' via kasan-dev
<[email protected]> wrote:
I'm concerned that the context_lock_struct() macro will make code harder
to read. Anyone who encounters the context_lock_struct() macro will have
to look up its definition to learn what it does. I propose to split this
macro into two macros:
* One macro that expands into "__ctx_lock_type(name)".
* A second macro that expands into the rest of the above macro.
In other words, instead of having to write
context_lock_struct(struct_name, { ... }); developers will have to write
struct context_lock_type struct_name {
...;
};
context_struct_helper_functions(struct_name);
This doesn't necessarily help with not having to look up its
definition to learn what it does.
If this is the common pattern, it will blindly be repeated, and this
adds 1 more line and makes this a bit more verbose. Maybe the helper
functions aren't always needed, but I also think that context lock
types should remain relatively few. For all synchronization
primitives that were enabled in this series, the helpers are required.
The current usage is simply:
context_lock_struct(name) {
... struct goes here ...
}; // note no awkward ) brace
I don't know which way the current kernel style is leaning towards,
but if we take <linux/cleanup.h> as an example, a simple programming
model / API is actually preferred.
Many kernel developers are used to look up the definition of a data
structure either by using ctags, etags or a similar tool or by using
grep and a pattern like "${struct_name} {\$". Breaking the tools kernel
developer use today to look up data structure definitions might cause
considerable frustration and hence shouldn't be done lightly.
Thanks,
Bart.
