summaryrefslogtreecommitdiff
path: root/arch/ia64/Makefile
AgeCommit message (Collapse)Author
2008-07-17Pull pvops into release branchTony Luck
2008-06-16[IA64] Fix CONFIG_IA64_SGI_UV build errorJack Steiner
Fix build error in CONFIG_IA64_SGI_UV config. (GENERIC builds are ok). Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-05-27[IA64] pvops: paravirtualize NR_IRQSIsaku Yamahata
Make NR_IRQ overridable by each pv instances. Pv instance may need each own number of irqs so that NR_IRQS should be the maximum number of nr_irqs each pv instances need. Cc: Jes Sorensen <jes@sgi.com> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-05-14[IA64] machvec support for SGI UV platformJack Steiner
This patch adds the basic IA64 machvec infrastructure to support the SGI "UV" platform. Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-04-27KVM: ia64: Enable kvm build for ia64Xiantao Zhang
Update the related Makefile and KConfig for kvm build Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-04[IA64] move defconfig to arch/ia64/configs/Adrian Bunk
This patch moves the default ia64 defconfig to arch/ia64/configs/generic_defconfig where it belongs and selects it as the default defconfig through KBUILD_DEFCONFIG. Signed-off-by: Adrian Bunk <adrian.bunk@movial.fi> Signed-off-by: Tony Luck <tony.luck@intel.com>
2007-12-07[IA64] don't assume that unwcheck.py is executableAndrew Morton
Don't assume that this file has execute permissions. For example, patch(1) loses that information. Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2007-10-15kbuild: enable 'make CPPFLAGS=...' to add additional options to CPPSam Ravnborg
The variable CPPFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. This patch replace use of CPPFLAGS with KBUILD_CPPFLAGS all over the tree and enabling one to use: make CPPFLAGS=... to specify additional CPP commandline options. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-14kbuild: enable 'make CFLAGS=...' to add additional options to CCSam Ravnborg
The variable CFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. On top of that several people over time has asked for a way to pass in additional flags to gcc. This patch replace use of CFLAGS with KBUILD_CFLAGS all over the tree and enabling one to use: make CFLAGS=... to specify additional gcc commandline options. One usecase is when trying to find gcc bugs but other use cases has been requested too. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k Test was simple to do a defconfig build, apply the patch and check that nothing got rebuild. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-06-21[IA64] add vmlinuz targetAlex Williamson
This is a trivial stand-alone patch out of the Xen/ia64 patches. Add a vmlinuz build target to be more compatible with x86-ish targets. Signed-off-by: Alex Williamson <alex.williamson@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-03-06kbuild: change kbuild to not rely on incorrect GNU make behaviorPaul Smith
The kbuild system takes advantage of an incorrect behavior in GNU make. Once this behavior is fixed, all files in the kernel rebuild every time, even if nothing has changed. This patch ensures kbuild works with both the incorrect and correct behaviors of GNU make. For more details on the incorrect behavior, see: http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html Changes in this patch: - Keep all targets that are to be marked .PHONY in a variable, PHONY. - Add .PHONY: $(PHONY) to mark them properly. - Remove any $(PHONY) files from the $? list when determining whether targets are up-to-date or not. Signed-off-by: Paul Smith <psmith@gnu.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-01-08kbuild: remove GCC_VERSIONSam Ravnborg
This was causing some ordering problems. Remove the up-front evaluation and just revaluate the compiler version each time we need it. (The up-front evaluation was problematic because some architectures modify the value of $(CC)). Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-09-13[IA64] fix circular dependency on generation of asm-offsets.hTony Luck
Fix? One ugly hack is replaced by a different ugly hack. Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-09-11kbuild: rename prepare to archprepare to fix dependency chainSam Ravnborg
When introducing the generic asm-offsets.h support the dependency chain for the prepare targets was changed. All build scripts expecting include/asm/asm-offsets.h to be made when using the prepare target would broke. With the limited number of prepare targets left in arch Makefiles the trivial solution was to introduce a new arch specific target: archprepare The dependency chain looks like this now: prepare | +--> prepare0 | +--> archprepare | +--> scripts_basic +--> prepare1 | +---> prepare2 | +--> prepare3 So prepare 3 is processed before prepare2 etc. This guaantees that the asm symlink, version.h, scripts_basic are all updated before archprepare is processed. prepare0 which build the asm-offsets.h file will need the actions performed by archprepare. The head target is now named prepare, because users scripts will most likely use that target, but prepare-all has been kept for compatibility. Updated Documentation/kbuild/makefiles.txt. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-09-09kbuild: ia64 use generic asm-offsets.h supportSam Ravnborg
Delete obsolete stuff from arch Makefile Rename file to asm-offsets.h The trick used in the arch Makefile to circumvent the circular dependency is kept. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
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!