[PATCH 0/10] m68k/thread_info merge

[PATCH 0/10] m68k/thread_info merge

[Roman Zippel]

Hi,

This patch series brings the m68k closer to a working state. It consists 
of two basic parts, the first five patches do the minimal changes to get 
m68k compiling in mainline, the last five patches do a cleanup of the 
kernel API.

The patches are against -mm, but the only conflict for the second patch to 
mainline is caused by this change in sched-cleanups.patch:

-		unsigned long * n = (unsigned long *) (p->thread_info+1);
+		unsigned long *n = (unsigned long *) (p->thread_info+1);

so either way it's easy to deal with.

The first four patches were done by Al and I mostly fixed the m68k 
specific parts, the other changes are:
patch 2: Rename setup_thread_info into setup_thread_stack to better 
reflect what it really does and adjust the arguments to reduce ordering 
requirements.
patch 3: move the thread_info.h include to preempt.h as this is the one 
that needs current_thread_info().

The second part reduces the role of thread_info and makes the thread stack 
more visible. The main change of these patches is the change from the 
thread_info to the stack field in task_struct to abstract away the direct 
access to the thread_info. I have been very careful with these changes 
(e.g. I manually reverted the patches and compared the result to prevent 
typos), so I'm quite sure these patches don't introduce any new problems.

There is one final patch pending to remove the thread_info field (and fix 
the users only in -mm), I'll send it when the other patches have been 
merged with an extra warning to linux-arch, so archs can catch up with the 
changes, if they should have larger unmerged patches. This is the only 
patch which could produce compile problem in case I might have missed 
something, but these will be easy to deal with.

bye, Roman

Re: [PATCH 0/10] m68k/thread_info merge

[Andrew Morton]

Roman Zippel <zippel@linux-m68k.org> wrote:
>
> This patch series brings the m68k closer to a working state. It consists 
> of two basic parts, the first five patches do the minimal changes to get 
> m68k compiling in mainline, the last five patches do a cleanup of the 
> kernel API.

Can I assume that the five m68k patches can be split apart from the five
patches which dink with task_struct?  ie: if the task_struct patches go in
later, does anything bad happen?

Re: [PATCH 0/10] m68k/thread_info merge

[Andrew Morton]

Andrew Morton <akpm@osdl.org> wrote:
>
> Can I assume that the five m68k patches can be split apart from the five
> patches which dink with task_struct?  ie: if the task_struct patches go in
> later, does anything bad happen?

eh, forget I asked that.  They're interdependent.

Re: [PATCH 0/10] m68k/thread_info merge

[viro]

On Thu, Sep 01, 2005 at 05:17:38PM -0700, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > Can I assume that the five m68k patches can be split apart from the five
> > patches which dink with task_struct?  ie: if the task_struct patches go in
> > later, does anything bad happen?
> 
> eh, forget I asked that.  They're interdependent.

... but do not have to be.

Re: [PATCH 0/10] m68k/thread_info merge

[Roman Zippel]

Hi,

On Thu, 1 Sep 2005, Andrew Morton wrote:

> Andrew Morton <akpm@osdl.org> wrote:
> >
> > Can I assume that the five m68k patches can be split apart from the five
> > patches which dink with task_struct?  ie: if the task_struct patches go in
> > later, does anything bad happen?
> 
> eh, forget I asked that.  They're interdependent.

Actually they shouldn't be, unless I missed something.
Especially if there should be a conflict in the last three patches with 
some other patch, you can drop the conflicting part in my patch and I'll 
fix it up later.

bye, Roman