On Fri, Jul 20, 2012 at 10:56:37PM +0100, David Howells wrote: > > Here's the second installment of patches from step 1 of my plan below to clean > up the kernel header files and sort out the inclusion recursion problems. > > Note that these patches will need regenerating if the header files they alter > change before they're applied. However, the disintegration is scripted, so > that just takes a few minutes normally. > > > =================================== > BACKGROUND ON THE RECURSION PROBLEM > =================================== > > 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 header 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. Other > splits and rearrangements could help also. > > 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. > > In the past 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 - each header needed to be included before the other.
Indeed, and later attempts to work around this problem using per-CPU variables did not go well either. This separation should allow __rcu_read_lock() to be inlined for PREEMPT=y kernels, which would be quite nice. Acked-by: Paul E. McKenney <paul...@linux.vnet.ibm.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
