[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070405182407.a785b895.akpm@linux-foundation.org>
Date: Thu, 5 Apr 2007 18:24:07 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Davide Libenzi <davidel@...ilserver.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/3] epoll cleanups - epoll include diet ...
On Thu, 5 Apr 2007 18:12:58 -0700 (PDT)
Davide Libenzi <davidel@...ilserver.org> wrote:
> On Thu, 5 Apr 2007, Andrew Morton wrote:
>
> > epoll uses signal stuff and might need signal.h. It implements syscalls
> > and it certainly needs to have those syscall's prototypes in scope. It
> > surely uses stuff from mm.h (doesn't everything??)
>
> Ack about signal.h, I forgot about the pwait code :(
> Why syscalls.h? The eventpoll.c file expots syscalls, but it doesn't use
> anything declared in there.
So that the compiler can verify that our declarations of sys_epoll_foo()
match our definitions of them.
> What does eventpoll.c use *directly* from mm.h? If eventpoll.c uses, let's
> say sched.h, and sched.h needs mm.h, it is sched.h responsibility to
> include the mm.h file not eventpoll.c one.
>
Sure. But if epoll.c _does_ use something from mm.h (or uses something
from a header which mm.h includes) then if we later remove the #include
mm.h from sched.h, eventpoll.c will break.
The general rule is: include in .c the header files which provide the stuff
which that .c file uses. Now, it maybe that eventpoll.c indeed uses nothing
which mm.h provides, and nothing which mm.h's includees provide. But it is
non-trivial to prove that. Once added, includes are hard to remove :(
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists