From: Peter Zijlstra <peterz@infradead.org>
To: balbi@ti.com
Cc: David Cohen <dacohen@gmail.com>,
linux-kernel@vger.kernel.org, mingo@elte.hu,
linux-omap@vger.kernel.org, linux-media@vger.kernel.org,
Alexey Dobriyan <adobriyan@gmail.com>,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH v2 1/1] headers: fix circular dependency between linux/sched.h and linux/wait.h
Date: Mon, 21 Feb 2011 17:43:27 +0100 [thread overview]
Message-ID: <1298306607.24121.18.camel@twins> (raw)
In-Reply-To: <20110221162939.GK23087@legolas.emea.dhcp.ti.com>
On Mon, 2011-02-21 at 18:29 +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 21, 2011 at 05:20:45PM +0100, Peter Zijlstra wrote:
> > > > I think Alexey already told you what you done wrong.
> > > >
> > > > Also, I really don't like the task_state.h header, it assumes a lot of
> > > > things it doesn't include itself and only works because its using macros
> > > > and not inlines at it probably should.
> > >
> > > Like wait.h I'd say. The main issue is wait.h uses TASK_* macros but
> > > cannot properly include sched.h as it would create a circular
> > > dependency. So a file including wait.h is able to compile because the
> > > dependency of sched.h relies on wake_up*() macros and it's not always
> > > used.
> > > We can still drop everything else from task_state.h but the TASK_*
> > > macros and then the problem you just pointed out won't exist anymore.
> > > What do you think about it?
> >
> > I'd much rather see a real cleanup.. eg. remove the need for sched.h to
> > include wait.h.
>
> isn't that exactly what he's trying to achieve ? Moving TASK_* to its
> own header is one approach, what other approach do you suggest ?
No, he's making a bigger mess, and didn't I just make another
suggestion?
> > afaict its needed because struct signal_struct and struct sighand_struct
> > include a wait_queue_head_t. The inclusion seems to come through
>
> yes.
Is that a qualified statement that, yes, that is the only inclusion
path?
> > completion.h, but afaict we don't actually need to include completion.h
> > because all we have is a pointer to a completion, which is perfectly
> > fine with an incomplete type.
>
> so maybe just dropping completion.h from sched.h would do it.
No, that will result in non-compilation due to wait_queue_head_t usage.
> > This all would suggest we move the signal bits into their own header
> > (include/linux/signal.h already exists and seems inviting).
> >
> > And then make sched.c include signal.h and completion.h.
>
> you wouldn't prevent the underlying problem which is the need to include
> sched.h whenever you include wait.h and use wake_up*()
If you'd applied your brain for a second before hitting reply you'd have
noticed that at this point you'd (likely) be able to include sched.h
from wait.h. which is the right way about, you need to be able to
schedule in order to build waitqueues.
next prev parent reply other threads:[~2011-02-21 16:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-21 14:38 [PATCH v2 0/1] Fix linux/wait.h header file David Cohen
2011-02-21 14:38 ` [PATCH v2 1/1] headers: fix circular dependency between linux/sched.h and linux/wait.h David Cohen
2011-02-21 15:54 ` Peter Zijlstra
2011-02-21 16:03 ` David Cohen
2011-02-21 16:20 ` Peter Zijlstra
2011-02-21 16:29 ` Felipe Balbi
2011-02-21 16:43 ` Peter Zijlstra [this message]
2011-02-21 16:54 ` Felipe Balbi
2011-02-21 17:06 ` Peter Zijlstra
2011-02-21 17:18 ` Felipe Balbi
2011-02-21 19:21 ` Alexey Dobriyan
2011-02-21 17:21 ` Oleg Nesterov
2011-02-21 17:27 ` Oleg Nesterov
2011-02-22 15:38 ` David Cohen
2011-02-21 16:33 ` [PATCH v2 0/1] Fix linux/wait.h header file Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1298306607.24121.18.camel@twins \
--to=peterz@infradead.org \
--cc=adobriyan@gmail.com \
--cc=balbi@ti.com \
--cc=dacohen@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox