On Mon, Nov 15, 2010 at 08:34:40PM +0000, David Holland wrote: > (moving this to tech-kern because it's the right place and per request) > > On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote: > > > 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! > > *bow* > > > 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...) > > I'm not sure this is a good plan in the long run. Shouldn't it at some > point be unhooked fully from the "real" proc structure? > > > - sys/syscallargs.h should be split into pieces, otherwise all its > > users have to know unrelated types (sys/mount.h, sys/cpu.h). > > Since system calls don't in general pass structures by value, it > shouldn't need most of those header files, just forward declarations > of the structs. > > (this is, btw, one of the reasons to avoid silly typedefs)
OK, you're absolutely right. And I'm fully agree that forward decls are better in modularity POV. > > > - 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. > > Given that this is a deprecated API in the long term I'm not sure it's > worthwhile. > > -- > David A. Holland > dholl...@netbsd.org -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635