Re: Getting kernel.org kernel to build for m68k?

[Roman Zippel]

Hi,

On Sun, 5 Sep 2004, Christoph Hellwig wrote:

> Because we don't want gazillions of special cases in common code.  We
> already added support for allocating the thread_info and task_struct
> as a single object because ia64 needed it, there's no reason to stack
> another hack ontop for m68k.

What ia64 is doing is already a hack and doesn't really apply to m68k, as 
we want to keep the stack separate.
The basic problem is something completely different, as soon as an arch 
wants to reorganize some data structures a bit different you are in 
include hell. The problem are the mixture of structure definitions and 
inline functions, as soon as inline functions use functions/structures not 
defined in the same file, the include dependencies become very fragile.
So we either have the choice we only use macros or we separate some core 
data types into their own headers (well, the only other option is that 
m68k has to stack more hacks on the ia64 hack).
So as soon as one wants to allocate thread_info and task_struct together 
without using hacks, one very populuar problem are the various lock 
functions and their use of preempt_enable(), which needs access to 
thread_info, but sched.h (and so task_struct) needs the definition of 
various data structures. The spinlock functions are all still macros, but 
a lot of other lock functions, which were added after the stack/ 
task_struct split, are real inline functions and make a reorganization 
very painful.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/