Hi Arnd,

On 11/19/21 15:47, Arnd Bergmann wrote:

On Fri, Nov 19, 2021 at 12:36 PM Alejandro Colomar
[off-list ref] wrote:

quoted

Alejandro Colomar (17):
  linux/container_of.h: Add memberof(T, m)
  Use memberof(T, m) instead of explicit NULL dereference
  Replace some uses of memberof() by its wrappers
  linux/memberof.h: Move memberof() to separate header
  linux/typeof_member.h: Move typeof_member() to a separate header
  Simplify sizeof(typeof_member()) to sizeof_field()
  linux/NULL.h: Move NULL to a separate header
  linux/offsetof.h: Move offsetof(T, m) to a separate header
  linux/offsetof.h: Implement offsetof() in terms of memberof()
  linux/container_of.h: Implement container_of_safe() in terms of
    container_of()
  linux/container_of.h: Cosmetic
  linux/container_of.h: Remove unnecessary cast to (void *)

My feeling is that this takes the separation too far: by having this many header
files that end up being included from practically every single .c file
in the kernel,
I think you end up making compile speed worse overall.

If your goal is to avoid having to recompile as much of the kernel
after touching
a header, I think a better approach is to help untangle the dependencies, e.g.
by splitting out type definitions from headers with inline functions (most
indirect header dependencies are on type definitions) and by focusing on
linux/fs.h, linux/sched.h, linux/mm.h and how they interact with the rest of the
headers. At the moment, these are included in most .c files and they in turn
include a ton of other headers.

Yes, I would like to untangle the dependencies.

The main reason I started doing this splitting
is because I wouldn't be able to include
<linux/stddef.h> in some headers,
because it pulled too much stuff that broke unrelated things.

So that's why I started from there.

I for example would like to get NULL in memberof()
without puling anything else,
so <linux/NULL.h> makes sense for that.

It's clear that every .c wants NULL,
but it's not so clear that every .c wants
everything that <linux/stddef.h> pulls indirectly.

But I'll note that linux/fs.h, linux/sched.h, linux/mm.h are
interesting headers for further splitting.


BTW, I also have a longstanding doubt about
how header files are organized in the kernel,
and which headers can and cannot be included
from which other files.

For example I see that files in samples or scripts or tools,
that redefine many things such as offsetof() or ARRAY_SIZE(),
and I don't know if there's a good reason for that,
or if I should simply remove all that stuff and
include <linux/offsetof.h> everywhere I see offsetof() being used.



Thanks,
Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel