Messages in this thread | | | Date | Thu, 25 Aug 2005 14:07:38 +0100 | From | Al Viro <> | Subject | Re: [PATCH] (18/22) task_thread_info - part 2/4 |
| |
On Thu, Aug 25, 2005 at 11:15:24AM +0200, Roman Zippel wrote: > > > > - *ti = *orig->thread_info; > > *tsk = *orig; > > + setup_thread_info(tsk, ti); > > tsk->thread_info = ti; > > ti->task = tsk; > > This introduces a subtle ordering requirement, where setup_thread_info > magically finds in the new task_struct the pointer to the old thread_info > to setup the new thread_info.
Nothing subtle with it, especially since this is the only place with any business to call setup_thread_info().
> What is your problem with what I have in CVS? There it completes the basic > task_struct setup and _after_ that it can setup the thread_info.
Which buys you what, exactly? You end up with more things to do in setup_thread_info() and it doesn't get cleaner.
> Al, I would really prefer to merge this one myself, I'm only waiting for > the 2.6.13 release and since this is not a regression, I don't really > understand why this must be in 2.6.13.
Fine, as long as that merge is done before your s/thread_info/stack/ patches. It should be the first step before doing 200Kb worth of cosmetical stuff that affects every architecture out there, not something that depends on it done.
There's also a question of having mainline build and work on the architecture in question, which obviously is not something you care about - this hairball had been sitting in m68k CVS for how long? Since 2.5.60-something, with zero efforts to resolve it, right? And mainline kernel didn't even build, let alone work since that moment.
FWIW, essentially the same splitup of that mess had been posted more than three months ago; definitely before 2.6.12-final. Still no activity _and_ plans that involve doing kernel-wide renaming of struct thread_info * thread_info in task_struct to void *stack as part of m68k merge. With 200-odd Kb of patches just out of that renaming. At which point I gave up on explaining the difference between "take the diff between mainline and CVS + whatever needed to make all other platforms compile after change and try to shove it into mainline" and "do minimally intrusive merge, followed by sane cleanup sequence done in mainline". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |