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 ? > afaict its needed because struct signal_struct and struct sighand_struct > include a wait_queue_head_t. The inclusion seems to come through yes. > 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. > 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*() -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
