Messages in this thread | | | From | Keith Owens <> | Subject | Re: 64-bit jiffies, a better solution take 2 | Date | Sun, 12 May 2002 09:38:48 +1000 |
| |
On Sat, 11 May 2002 19:11:18 +0100, Russell King <rmk@arm.linux.org.uk> wrote: >On Sat, May 11, 2002 at 10:37:39AM -0700, Linus Torvalds wrote: >> On Sat, 11 May 2002, george anzinger wrote: >> > >> > So, what to do? For ARM and MIPS we could go back to solution 1: >> >> Why not just put that knowledge in the ARM/MIPS architecture makefile? >> >> ARM already has multiple linker scripts, and it already selects on them >> based on CONFIG options, so I'd much rather just do that straightforward >> kind of thing than play any clever games. > >So would I - there will be a config option, so we can just use sed on the >relevant linker script to do the right thing.
Any reason that you are using sed and not cpp like the other architectures?
The use and name of linker scripts varies across architectures, some use cpp, some use sed, some do not pre-process at all. This makes it awkward for repositories and dont-diff lists, they need special rules for every architecture. In kbuild 2.5 I am trying to standardize on arch/$(ARCH)/vmlinux.lds.S which is always pre-processed by cpp to vmlinux.lds.i which is used to link vmlinux.
Using .S -> .i has three benefits. The file name and the code for converting the file is standardized. Dont-diff lists exclude *.[oais] files, no need for special cases for each architecture. kbuild 2.5 tracks the command, timestamp and dependencies for all .S -> .i conversions so the ld script will become a properly controlled file, being rebuilt when necessary and only when necessary.
For architectures that need to choose between multiple ld scripts. In my tree I have made the ld script name a variable (arch_ld_script) that may be set in arch/$(ARCH)/Makefile.defs.config. If the variable is not set, it defaults to /arch/$(ARCH)/vmlinux.lds.i.
- 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/
| |