mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Andi Kleen <ak@muc.de>, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Modernize i386 string.h
Date: Mon, 19 Jan 2004 10:06:38 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.53.0401191003070.6753@chaos> (raw)
In-Reply-To: <400BE923.1020505@pobox.com>

On Mon, 19 Jan 2004, Jeff Garzik wrote:

> Andi Kleen wrote:
> > This patch modernizes i386 string.h. It removes all the fragile i386
> > inline str* functions and just switches to gcc's builtin variants.
> > Modern gcc should generate equivalent or better code. Sometimes it
> > calls out-of-line code, in that case the standard C functions in
> > lib/string.c is used.
> [...]
> > diff -u linux-string/arch/i386/kernel/i386_ksyms.c-STRING linux-string/arch/i386/kernel/i386_ksyms.c
> > --- linux-string/arch/i386/kernel/i386_ksyms.c-STRING	2003-10-09 00:28:44.000000000 +0200
> > +++ linux-string/arch/i386/kernel/i386_ksyms.c	2004-01-18 13:26:36.479533784 +0100
> > @@ -133,6 +133,38 @@
> >  EXPORT_SYMBOL(pcibios_get_irq_routing_table);
> >  #endif
> >
> > +/* Export string functions. We normally rely on gcc builtin for most of these,
> > +   but gcc sometimes decides not to inline them. */
> > +#undef memchr
> > +#undef strlen
> > +#undef strcpy
> > +#undef strncmp
> > +#undef strncpy
> > +#undef strchr
> > +#undef strcmp
> > +#undef strcpy
> > +#undef strcat
> > +
> > +extern size_t strlen(const char *);
> > +extern char * strcpy(char * dest,const char *src);
> > +extern int strcmp(const char * cs,const char * ct);
> > +extern void *memchr(const void *s, int c, size_t n);
> > +extern char * strcat(char *, const char *);
>
> ISTR this patch being shot down in the past...
>
> It seems suboptimal for people with ancient compilers, or for people on
> embedded 486's, doesn't it?
>
> 	Jeff
>

I don't think so. It helps reduce the size of the code by having
only one copy of each routine in memory rather than zillions.

If your code can't stand the overhead of the call/return, then
you put some inline code at that particular place, not everywhere!

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.



  reply	other threads:[~2004-01-19 15:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-18 20:09 Andi Kleen
2004-01-19 14:26 ` Jeff Garzik
2004-01-19 15:06   ` Richard B. Johnson [this message]
2004-01-19 15:10   ` Andi Kleen
2004-01-20  0:49 ` Richard Henderson
2004-01-20  1:39   ` Andi Kleen
2004-01-20  2:04 ` Rusty Russell

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=Pine.LNX.4.53.0401191003070.6753@chaos \
    --to=root@chaos.analogic.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    /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®