[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/powerpc/oea
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!
> > 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
> David A. Holland
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Main Index |
Thread Index |