On Fri, Nov 19, 2021 at 04:06:27PM +0100, Alejandro Colomar (man-pages) wrote:

Hi Arnd,

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

quoted

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.

I don't believe that the code that uses NULL won't include types.h.

-- 
With Best Regards,
Andy Shevchenko



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