mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Russell King <rmk@arm.linux.org.uk>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: 64-bit jiffies, a better solution take 2
Date: Sun, 12 May 2002 10:31:06 +1000	[thread overview]
Message-ID: <16925.1021163466@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Sun, 12 May 2002 01:01:21 +0100." <20020512010121.A23946@flint.arm.linux.org.uk>

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.

>From arch/$(ARCH)/Makefile.in

  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.


  reply	other threads:[~2002-05-12  0:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-22 15:12 How should we do a 64-bit jiffies? george anzinger
2001-10-23  5:10 ` Keith Owens
2001-10-23  6:05   ` Brian Gerst
2001-10-23  6:23     ` Keith Owens
2001-10-23  8:03   ` george anzinger
2001-10-23 15:45     ` Linus Torvalds
2001-10-26 20:59       ` george anzinger
     [not found]     ` <200110231545.f9NFjgg01377@penguin.transmeta.com>
2002-05-10 21:35       ` 64-bit jiffies, a better solution george anzinger
2002-05-10 21:52         ` Linus Torvalds
2002-05-10 22:36           ` george anzinger
2002-05-10 22:40             ` Linus Torvalds
2002-05-11  0:42               ` 64-bit jiffies, a better solution take 2 george anzinger
2002-05-11  8:29                 ` Russell King
2002-05-11 15:01                   ` george anzinger
2002-05-11 16:10                     ` Russell King
2002-05-11 17:31                       ` george anzinger
2002-05-11 17:37                         ` Linus Torvalds
2002-05-11 18:11                           ` Russell King
2002-05-11 23:38                             ` Keith Owens
2002-05-12  0:01                               ` Russell King
2002-05-12  0:31                                 ` Keith Owens [this message]
2002-05-12  8:12                                   ` george anzinger
     [not found]                             ` <3CDD6DA1.7B259EF1@mvista.com>
     [not found]                               ` <20020511201748.G1574@flint.arm.linux.org.uk>
2002-05-12  8:03                                 ` 64-bit jiffies, a better solution take 2 (Fix ARM) george anzinger
2002-05-11 16:41                     ` 64-bit jiffies, a better solution take 2 Daniel Jacobowitz
2002-05-13 11:09             ` 64-bit jiffies, a better solution Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16925.1021163466@ocs3.intra.ocs.com.au \
    --to=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®