While looking at code generated by gcc4.0 I noticed some functions still
had frame pointers, even after we stopped ppc64 from defining
CONFIG_FRAME_POINTER.  It turns out kernel/Makefile hardwires
-fno-omit-frame-pointer on when compiling schedule.c.

Create CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER and define it on architectures
that dont require frame pointers in sched.c code.

(akpm: blame me for the name)
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch contains the shim module (XP) which interfaces between the
communication module (XPC) and the functional support modules (like XPNET).
Signed-off-by: NDean Nelson <dcn@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Now that we have MC/MT detection patches in, appended patch allows us to
configure MT scheduler optimizations. For now, we will this option off
by default.

There is some discussion going on lkml about setting up sched-domains 
which are absolutely needed (like for example, we shouldn't setup SMT domain
for non MT processors). Once that patch goes in, we can enable this option by
default.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[IA64] fix ia64 Kconfig to allow CONFIG_PM on sn2

This probably should have been fixed when I fixed up the generic build for
discontig+numa machines, but oh well.

CONFIG_PM is allowable for generic builds but not for sn2 builds, which
doesn't make much sense, and in fact breaks the build if recent ACPI bits are
added to the tree.  It looks like the only arch that needs to prevent
CONFIG_PM stuff is the ski simulator (though those options could probably use
some cleanup as well), so remove the big conditional and replace it with a
simple test for IA64_HP_SIM instead.
Signed-off-by: NJesse Barnes <jbarnes@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!