On Nov,Monday 15 2010, at 7:16 AM, Bernd Ernesti wrote: > On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote: >> On Sun, Nov 14, 2010 at 05:52:51AM +0000, David Holland wrote: >>> On Sun, Nov 14, 2010 at 03:32:44AM +0000, Masao Uebayashi wrote: >>>> XXX What is the conclusion about direct vs. indirect #include from headers? >>> >>> Every header file should include the things it requires to compile. >>> Therefore, there should in principle be no cases where a header file >>> (or source file) needs to #include something it doesn't itself use. >> >> This clarifies my long-unanswered question, thanks! >> >> I've (re)built about 300 kernels in the last days. I've found: >> >> - sys/sysctl.h's struct kinfo_proc should be moved into sys/proc.h >> (I've done this locally). Otherwise all sysctl node providers >> includes sys/proc.h and uvm/uvm_extern.h. >> (This is where I started...) >> >> - sys/syscallargs.h should be split into pieces, otherwise all its >> users have to know unrelated types (sys/mount.h, sys/cpu.h). >> >> - sys/proc.h's tsleep(), wakeup(), and friends should be moved into >> some common header, because it's widely used API. sys/proc.h will >> be used only for "struct proc" related things. > > What are the issues here that we need to fix this right now?
I think that it's quite good time to fix, it would be much harder to do this after 6.0 branch. Regards Adam.