Randy Dunlap <rdunlap@xxxxxxxxxxxx> wrote: > Could you give a small bit of background on the "recursion problems," please? Well, I occasionally run into a problem where I can't write an inline function in a header file because I need to access something from another headerfile that includes this one. Due to this, I end up writing it as a #define instead. The problems are mainly due to inline functions. If we split some headers (linux/sched.h being the biggest culprit) to separate the inline functions from the data structs (e.g. task_struct) then we could reduce the problems. Quite often it's a case of an inline function in header A wanting a struct[*] from header B, but header B already has an inline function that wants a struct from header A. [*] or constant or whatever. Recently someone tried to add a kernel-offsets file (an analogue to asm-offsets) to deal with the problems of dealing with both linux/rcupdate.h and linux/sched.h. > > (7) Provide a script to go through and rejig the #includes of each source > > file to have just the ones that are actually required. > > How is "actually required" defined? > We traditionally want to see #include <hdrfile> for any interfaces that are > used, even if other header files suck in some other needed header files. Yes, but with the amount of copy'n'paste going on, there are quite a lot of unnecessary #includes in the codebase. Furthermore, headers sometimes get rearranged and new #includes added - and sometimes obsolete ones don't get removed. Whilst these aren't strictly a part of the recursion problem, what they do do is slow down recompilation by causing recompilation of things that didn't actually need it. > > (8) Provide a make target that tests all the KAPI and UAPI headers by > > simply passing them one at a time to the compiler and attempting to > > compile them. > > Interesting. If gcc can have its sources piped in, then this should be fairly straightforward. Admittedly, there may be some headers that can't go through this process as they're meant to be #included after #defining some parameters, but those can be flagged in some way. > > The uapi/ directories are also added with -I to the CPP flags after the > > include/ directories so that if the KAPI file does not exist, the UAPI file > > will be used directly. This is not as elegant as using #include_next might > > be, but it does work. > > Is this v2 patchset meant to avoid the use of #include_next? > I don't see that used, but patch 22 description refers to #include_next. Yeah... I need to vet the patch descriptions. Btw, what's your reason for disliking #include_next? Note that the kernel already uses it in places. David -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
