Re: 64-bit jiffies, a better solution take 2

Keith Owens (kaos@ocs.com.au)
Sun, 12 May 2002 10:31:06 +1000


On Sun, 12 May 2002 01:01:21 +0100,
Russell King <rmk@arm.linux.org.uk> wrote:
>On Sun, May 12, 2002 at 09:38:48AM +1000, Keith Owens wrote:
>> Any reason that you are using sed and not cpp like the other
>> architectures?
>
>Only historical and a hatred of cpp's "# line file" stuff, and the fact
>that ARM needs to use sed elsewhere in the build to get around broken
>GCC %c0 stuff.

extra_aflags(vmlinux.lds.i -U$(ARCH) -C -P)

-P suppresses the '# line file' stuff.

>I think we could actually get rid of the preprocessing of the linker
>files - see ld's defsym argument.

Some architectures need #ifdef in their script, they control more than
just values (sh, ia64). I like standard code, so use cpp for everything.

>> 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.
>
>Eww, so I can't use "find . -name '*.[cS]'" to find all the C source and
>assembly source with kbuild 2.5 because we've got pollution of the .S
>extension?

Don't blame kbuild 2.5 for that.

arch/ia64/vmlinux.lds.S
arch/mips64/ld.script.elf32.S
arch/sh/vmlinux.lds.S

I am just following the most common existing convention, trying to
minimize changes to existing files for kbuild 2.5.

>I'm not a fan of dont-diff stuff myself - I'd rather ensure a clean
>source tree and then diff rather than diffing a dirty built tree.

Then you must like separate source and object trees for kbuild 2.5 :)

>dont-diff stuff needs to be maintained and extended as stuff changes
>in the kernel tree, and lets face it, no amount of extension pollution
>will prevent it from being updated over time.

True, but we can try to minimize the special cases.

-
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/