Re: CVS commit: src/sys/arch/powerpc/oea

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

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
> dholland%netbsd.org@localhost

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635