* [RFC] cleanup patches for strings
@ 2005-06-20 22:46 Jesper Juhl
2005-06-21 6:58 ` cutaway
` (4 more replies)
0 siblings, 5 replies; 19+ messages in thread
From: Jesper Juhl @ 2005-06-20 22:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, Jeff Garzik, Domen Puncer
Hi,
I have a bunch (few hundred) of oneliners like the ones below lying around
on my HD and I'm wondering what the best way to submit them is.
The patches all make the same change, there's just a lot of files the
change needs to be made in. The change they make is to change strings
from the form
[const] char *foo = "blah";
to
[const] char foo[] = "blah";
The reason to do this was well explained by Jeff Garzik in the past (and
now found in the Kernel Janitors TODO) :
-----------------------------------------------------------------------------
From: Jeff Garzik <jgarzik at mandrakesoft dot com>
The string form
[const] char *foo = "blah";
creates two variables in the final assembly output, a static string, and
a char pointer to the static string. The alternate string form
[const] char foo[] = "blah";
is better because it declares a single variable.
For variables marked __initdata, the "*foo" form causes only the
pointer, not the string itself, to be dropped from the kernel image,
which is a bug. Using the "foo[]" form with regular 'ole local
variables also makes the assembly shorter.
-----------------------------------------------------------------------------
What I did was make a small sed script to blindly change all occourances
of the first form into the second. Of course this won't always work, since
the second form is not always good if we later assign something to the
variable, but it provided a starting point. I'm now in the process of
weeding out the false positives so that I'll be left with all the patches
that actually make a sane change.
As for submitting them. I was planning to split them into groups based on
top-level kernel source dirs, then concatenate all the patches for one dir
into one large patch and send it to lkml + CC:akpm (this would mean <=11
patches) - sending each patch to a sepperate maintainer would make it a
nightmare and would take ages. Andrew: would you be OK with that? Are
patches like these even wanted?
Below I've just picked 5 of my patches at random to show you what they
look like. These should not be merged yet.
--- linux-2.6.12-orig/drivers/isdn/hardware/avm/b1.c 2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.12/drivers/isdn/hardware/avm/b1.c 2005-06-20 00:04:10.000000000 +0200
@@ -28,7 +28,7 @@
#include <linux/isdn/capicmd.h>
#include <linux/isdn/capiutil.h>
-static char *revision = "$Revision: 1.1.2.2 $";
+static char revision[] = "$Revision: 1.1.2.2 $";
/* ------------------------------------------------------------- */
--- linux-2.6.12-orig/drivers/net/wireless/wavelan_cs.p.h 2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.12/drivers/net/wireless/wavelan_cs.p.h 2005-06-20 00:04:11.000000000 +0200
@@ -512,7 +512,7 @@
/************************ CONSTANTS & MACROS ************************/
#ifdef DEBUG_VERSION_SHOW
-static const char *version = "wavelan_cs.c : v24 (SMP + wireless extensions) 11/1/02\n";
+static const char version[] = "wavelan_cs.c : v24 (SMP + wireless extensions) 11/1/02\n";
#endif
/* Watchdog temporisation */
--- linux-2.6.12-orig/drivers/net/appletalk/cops.c 2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.12/drivers/net/appletalk/cops.c 2005-06-20 00:04:11.000000000 +0200
@@ -84,7 +84,7 @@ static const char *version =
* io regions, irqs and dma channels
*/
-static const char *cardname = "cops";
+static const char cardname[] = "cops";
#ifdef CONFIG_COPS_DAYNA
static int board_type = DAYNA; /* Module exported */
--- linux-2.6.12-orig/drivers/net/sun3lance.c 2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.12/drivers/net/sun3lance.c 2005-06-20 00:04:11.000000000 +0200
@@ -21,7 +21,7 @@
*/
-static char *version = "sun3lance.c: v1.2 1/12/2001 Sam Creasey (sammy@sammy.net)\n";
+static char version[] = "sun3lance.c: v1.2 1/12/2001 Sam Creasey (sammy@sammy.net)\n";
#include <linux/module.h>
#include <linux/stddef.h>
--- linux-2.6.12-orig/drivers/net/ibmlana.c 2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.12/drivers/net/ibmlana.c 2005-06-20 00:04:11.000000000 +0200
@@ -842,7 +842,7 @@ static int ibmlana_tx(struct sk_buff *sk
Sorry Linus for the filler string but I couldn't resist ;-) */
if (tmplen > skb->len) {
- char *fill = "NetBSD is a nice OS too! ";
+ char fill[] = "NetBSD is a nice OS too! ";
unsigned int destoffs = skb->len, l = strlen(fill);
while (destoffs < tmplen) {
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-20 22:46 [RFC] cleanup patches for strings Jesper Juhl
@ 2005-06-21 6:58 ` cutaway
2005-06-21 11:02 ` Denis Vlasenko
2005-06-21 8:59 ` Alexey Dobriyan
` (3 subsequent siblings)
4 siblings, 1 reply; 19+ messages in thread
From: cutaway @ 2005-06-21 6:58 UTC (permalink / raw)
To: Jesper Juhl, linux-kernel; +Cc: Andrew Morton, Jeff Garzik, Domen Puncer
Examine each case individually...
Any code that did a "sizeof(foo)" is [very] likely to give different
results.
Also, if there are several instances of "foo" being passed around as
parameter, you may find the generated code gets somewhat worse if "foo" used
to be a stack based autovar. On x86, the const[] implementation will always
cause a 5 byte PUSH for a parameter, whereas the autovar pointer
implementation often will be a shorter 3 byte EBP relative push. With many
instances of 'foo' usage (or used in a loop), you may be better off paying
the price of an autovar init during prolog to get the cheaper parm pushes
later.
----- Original Message -----
From: "Jesper Juhl" <juhl-lkml@dif.dk>
To: "linux-kernel" <linux-kernel@vger.kernel.org>
Cc: "Andrew Morton" <akpm@osdl.org>; "Jeff Garzik" <jgarzik@pobox.com>;
"Domen Puncer" <domen@coderock.org>
Sent: Monday, June 20, 2005 18:46
Subject: [RFC] cleanup patches for strings
> from the form
> [const] char *foo = "blah";
> to
> [const] char foo[] = "blah";
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-20 22:46 [RFC] cleanup patches for strings Jesper Juhl
2005-06-21 6:58 ` cutaway
@ 2005-06-21 8:59 ` Alexey Dobriyan
2005-06-21 9:31 ` Jörn Engel
2005-06-21 9:04 ` Andrey Panin
` (2 subsequent siblings)
4 siblings, 1 reply; 19+ messages in thread
From: Alexey Dobriyan @ 2005-06-21 8:59 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel, Andrew Morton, Jeff Garzik, Domen Puncer
On Tuesday 21 June 2005 02:46, Jesper Juhl wrote:
> The patches all make the same change, there's just a lot of files the
> change needs to be made in. The change they make is to change strings
> from the form
> [const] char *foo = "blah";
> to
> [const] char foo[] = "blah";
> Below I've just picked 5 of my patches at random to show you what they
> look like. These should not be merged yet.
> --- linux-2.6.12-orig/drivers/isdn/hardware/avm/b1.c
> +++ linux-2.6.12/drivers/isdn/hardware/avm/b1.c
> -static char *revision = "$Revision: 1.1.2.2 $";
> +static char revision[] = "$Revision: 1.1.2.2 $";
Looks good:
16323 104 0 16427 402b drivers/isdn/hardware/avm/b1.o 2.95.3-before
16291 104 0 16395 400b drivers/isdn/hardware/avm/b1.o 2.95.3-after
14643 104 0 14747 399b drivers/isdn/hardware/avm/b1.o 3.3.5-20050130-before
14621 104 0 14725 3985 drivers/isdn/hardware/avm/b1.o 3.3.5-20050130-after
15352 104 0 15456 3c60 drivers/isdn/hardware/avm/b1.o 4.1-20050604-before
15330 104 0 15434 3c4a drivers/isdn/hardware/avm/b1.o 4.1-20050604-after
> --- linux-2.6.12-orig/drivers/net/wireless/wavelan_cs.p.h
> +++ linux-2.6.12/drivers/net/wireless/wavelan_cs.p.h
> -static const char *version = "wavelan_cs.c : v24 (SMP + wireless extensions) 11/1/02\n";
> +static const char version[] = "wavelan_cs.c : v24 (SMP + wireless extensions) 11/1/02\n";
21018 456 0 21474 53e2 drivers/net/wireless/wavelan_cs.o 2.95.3-before
21018 424 0 21442 53c2 drivers/net/wireless/wavelan_cs.o 2.95.3-after
19707 424 12 20143 4eaf drivers/net/wireless/wavelan_cs.o 3.3.5-20050130-before
19707 392 12 20111 4e8f drivers/net/wireless/wavelan_cs.o 3.3.5-20050130-after
17950 424 12 => 18386 <= 47d2 drivers/net/wireless/wavelan_cs.o 4.1-20050604-before
17989 392 12 => 18393 <= 47d9 drivers/net/wireless/wavelan_cs.o 4.1-20050604-after
> --- linux-2.6.12-orig/drivers/net/appletalk/cops.c
> +++ linux-2.6.12/drivers/net/appletalk/cops.c
> -static const char *cardname = "cops";
> +static const char cardname[] = "cops";
Looks good:
14005 100 72 14177 3761 drivers/net/appletalk/cops.o 2.95.3-before
13989 96 72 14157 374d drivers/net/appletalk/cops.o 2.95.3-after
13308 112 72 13492 34b4 drivers/net/appletalk/cops.o 3.3.5-20050130-before
13305 112 72 13489 34b1 drivers/net/appletalk/cops.o 3.3.5-20050130-after
12948 112 72 13132 334c drivers/net/appletalk/cops.o 4.1-20050604-before
12945 112 72 13129 3349 drivers/net/appletalk/cops.o 4.1-20050604-after
> --- linux-2.6.12-orig/drivers/net/sun3lance.c
> +++ linux-2.6.12/drivers/net/sun3lance.c
> -static char *version = "sun3lance.c: v1.2 1/12/2001 Sam Creasey (sammy@sammy.net)\n";
> +static char version[] = "sun3lance.c: v1.2 1/12/2001 Sam Creasey (sammy@sammy.net)\n";
Be sure to have m68k cross-compiler handy.
> --- linux-2.6.12-orig/drivers/net/ibmlana.c
> +++ linux-2.6.12/drivers/net/ibmlana.c
> - char *fill = "NetBSD is a nice OS too! ";
> + char fill[] = "NetBSD is a nice OS too! ";
Don't:
5721 16 4 5741 166d drivers/net/ibmlana.o 2.95.3-before
5737 16 4 5757 167d drivers/net/ibmlana.o 2.95.3-after
5163 16 4 5183 143f drivers/net/ibmlana.o 3.3.5-20050130-before
5169 16 4 5189 1445 drivers/net/ibmlana.o 3.3.5-20050130-after
4993 16 4 5013 1395 drivers/net/ibmlana.o 4.1-20050604-before
5028 16 4 5048 13b8 drivers/net/ibmlana.o 4.1-20050604-after
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-20 22:46 [RFC] cleanup patches for strings Jesper Juhl
2005-06-21 6:58 ` cutaway
2005-06-21 8:59 ` Alexey Dobriyan
@ 2005-06-21 9:04 ` Andrey Panin
2005-06-21 10:59 ` Denis Vlasenko
2005-06-21 21:12 ` Horst von Brand
4 siblings, 0 replies; 19+ messages in thread
From: Andrey Panin @ 2005-06-21 9:04 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 5267 bytes --]
On 172, 06 21, 2005 at 12:46:26AM +0200, Jesper Juhl wrote:
> Hi,
>
> I have a bunch (few hundred) of oneliners like the ones below lying around
> on my HD and I'm wondering what the best way to submit them is.
>
> The patches all make the same change, there's just a lot of files the
> change needs to be made in. The change they make is to change strings
> from the form
> [const] char *foo = "blah";
> to
> [const] char foo[] = "blah";
>
> The reason to do this was well explained by Jeff Garzik in the past (and
> now found in the Kernel Janitors TODO) :
>
> -----------------------------------------------------------------------------
> From: Jeff Garzik <jgarzik at mandrakesoft dot com>
>
> The string form
>
> [const] char *foo = "blah";
>
> creates two variables in the final assembly output, a static string, and
> a char pointer to the static string. The alternate string form
>
> [const] char foo[] = "blah";
>
> is better because it declares a single variable.
>
> For variables marked __initdata, the "*foo" form causes only the
> pointer, not the string itself, to be dropped from the kernel image,
> which is a bug. Using the "foo[]" form with regular 'ole local
> variables also makes the assembly shorter.
> -----------------------------------------------------------------------------
>
> What I did was make a small sed script to blindly change all occourances
> of the first form into the second. Of course this won't always work, since
> the second form is not always good if we later assign something to the
> variable, but it provided a starting point. I'm now in the process of
> weeding out the false positives so that I'll be left with all the patches
> that actually make a sane change.
>
> As for submitting them. I was planning to split them into groups based on
> top-level kernel source dirs, then concatenate all the patches for one dir
> into one large patch and send it to lkml + CC:akpm (this would mean <=11
> patches) - sending each patch to a sepperate maintainer would make it a
> nightmare and would take ages. Andrew: would you be OK with that? Are
> patches like these even wanted?
>
>
> Below I've just picked 5 of my patches at random to show you what they
> look like. These should not be merged yet.
>
>
> --- linux-2.6.12-orig/drivers/isdn/hardware/avm/b1.c 2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.12/drivers/isdn/hardware/avm/b1.c 2005-06-20 00:04:10.000000000 +0200
> @@ -28,7 +28,7 @@
> #include <linux/isdn/capicmd.h>
> #include <linux/isdn/capiutil.h>
>
> -static char *revision = "$Revision: 1.1.2.2 $";
> +static char revision[] = "$Revision: 1.1.2.2 $";
>
> /* ------------------------------------------------------------- */
>
> --- linux-2.6.12-orig/drivers/net/wireless/wavelan_cs.p.h 2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.12/drivers/net/wireless/wavelan_cs.p.h 2005-06-20 00:04:11.000000000 +0200
> @@ -512,7 +512,7 @@
> /************************ CONSTANTS & MACROS ************************/
>
> #ifdef DEBUG_VERSION_SHOW
> -static const char *version = "wavelan_cs.c : v24 (SMP + wireless extensions) 11/1/02\n";
> +static const char version[] = "wavelan_cs.c : v24 (SMP + wireless extensions) 11/1/02\n";
> #endif
>
> /* Watchdog temporisation */
>
> --- linux-2.6.12-orig/drivers/net/appletalk/cops.c 2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.12/drivers/net/appletalk/cops.c 2005-06-20 00:04:11.000000000 +0200
> @@ -84,7 +84,7 @@ static const char *version =
> * io regions, irqs and dma channels
> */
>
> -static const char *cardname = "cops";
> +static const char cardname[] = "cops";
>
> #ifdef CONFIG_COPS_DAYNA
> static int board_type = DAYNA; /* Module exported */
>
> --- linux-2.6.12-orig/drivers/net/sun3lance.c 2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.12/drivers/net/sun3lance.c 2005-06-20 00:04:11.000000000 +0200
> @@ -21,7 +21,7 @@
>
> */
>
> -static char *version = "sun3lance.c: v1.2 1/12/2001 Sam Creasey (sammy@sammy.net)\n";
> +static char version[] = "sun3lance.c: v1.2 1/12/2001 Sam Creasey (sammy@sammy.net)\n";
>
> #include <linux/module.h>
> #include <linux/stddef.h>
>
> --- linux-2.6.12-orig/drivers/net/ibmlana.c 2005-06-17 21:48:29.000000000 +0200
> +++ linux-2.6.12/drivers/net/ibmlana.c 2005-06-20 00:04:11.000000000 +0200
> @@ -842,7 +842,7 @@ static int ibmlana_tx(struct sk_buff *sk
> Sorry Linus for the filler string but I couldn't resist ;-) */
>
> if (tmplen > skb->len) {
> - char *fill = "NetBSD is a nice OS too! ";
> + char fill[] = "NetBSD is a nice OS too! ";
This string definitely needs static const attribute.
> unsigned int destoffs = skb->len, l = strlen(fill);
>
> while (destoffs < tmplen) {
>
>
> -
> 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/
>
--
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 8:59 ` Alexey Dobriyan
@ 2005-06-21 9:31 ` Jörn Engel
2005-06-21 20:47 ` Jesper Juhl
0 siblings, 1 reply; 19+ messages in thread
From: Jörn Engel @ 2005-06-21 9:31 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Jesper Juhl, linux-kernel, Andrew Morton, Jeff Garzik,
Domen Puncer
On Tue, 21 June 2005 12:59:22 +0400, Alexey Dobriyan wrote:
>
> > --- linux-2.6.12-orig/drivers/net/ibmlana.c
> > +++ linux-2.6.12/drivers/net/ibmlana.c
>
> > - char *fill = "NetBSD is a nice OS too! ";
> > + char fill[] = "NetBSD is a nice OS too! ";
>
> Don't:
> 5721 16 4 5741 166d drivers/net/ibmlana.o 2.95.3-before
> 5737 16 4 5757 167d drivers/net/ibmlana.o 2.95.3-after
> 5163 16 4 5183 143f drivers/net/ibmlana.o 3.3.5-20050130-before
> 5169 16 4 5189 1445 drivers/net/ibmlana.o 3.3.5-20050130-after
> 4993 16 4 5013 1395 drivers/net/ibmlana.o 4.1-20050604-before
> 5028 16 4 5048 13b8 drivers/net/ibmlana.o 4.1-20050604-after
Please note that all the Dos have the magic word "static" while this
Don't doesn't.
Jörn
--
It is better to die of hunger having lived without grief and fear,
than to live with a troubled spirit amid abundance.
-- Epictetus
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-20 22:46 [RFC] cleanup patches for strings Jesper Juhl
` (2 preceding siblings ...)
2005-06-21 9:04 ` Andrey Panin
@ 2005-06-21 10:59 ` Denis Vlasenko
2005-06-21 21:24 ` Jean Delvare
2005-06-21 21:12 ` Horst von Brand
4 siblings, 1 reply; 19+ messages in thread
From: Denis Vlasenko @ 2005-06-21 10:59 UTC (permalink / raw)
To: Jesper Juhl, linux-kernel; +Cc: Andrew Morton, Jeff Garzik, Domen Puncer
On Tuesday 21 June 2005 01:46, Jesper Juhl wrote:
> Hi,
>
> I have a bunch (few hundred) of oneliners like the ones below lying around
> on my HD and I'm wondering what the best way to submit them is.
I have 361813 bytes in 292 patches for:
- printk(KERN_ERR "%s: start receive command failed \n", dev->name);
+ printk(KERN_ERR "%s: start receive command failed\n", dev->name);
type patches. Are these needed?
In case you wonder whether YOUR driver has such things, the list:
total 1264
-rwxr-xr-x 1 root root 15234 Jun 17 00:47 3c359.c.patch
-rwxr-xr-x 1 root root 507 Jun 17 00:47 3c505.c.patch
-rwxr-xr-x 1 root root 1052 Jun 17 00:47 53c7xx.c.patch
-rwxr-xr-x 1 root root 795 Jun 17 00:47 BusLogic.c.patch
-rwxr-xr-x 1 root root 409 Jun 17 00:47 CodingStyle.patch
-rwxr-xr-x 1 root root 695 Jun 17 00:47 NCR5380.c.patch
-rwxr-xr-x 1 root root 1010 Jun 17 00:47 NCR53C9x.c.patch
-rwxr-xr-x 1 root root 447 Jun 17 00:47 acpi_memhotplug.c.patch
-rwxr-xr-x 1 root root 4785 Jun 17 00:47 addRamDisk.c.patch
-rwxr-xr-x 1 root root 716 Jun 17 00:47 af_wanpipe.c.patch
-rwxr-xr-x 1 root root 1383 Jun 17 00:47 aha1542.c.patch
-rwxr-xr-x 1 root root 505 Jun 17 00:47 aha1740.c.patch
-rwxr-xr-x 1 root root 430 Jun 17 00:47 airo.c.patch
-rwxr-xr-x 1 root root 5728 Jun 17 00:47 ali-ircc.c.patch
-rwxr-xr-x 1 root root 468 Jun 17 00:47 ali5451.c.patch
-rwxr-xr-x 1 root root 762 Jun 17 00:47 ali5455.c.patch
-rwxr-xr-x 1 root root 537 Jun 17 00:47 amd64-agp.c.patch
-rwxr-xr-x 1 root root 644 Jun 17 00:47 apm.c.patch
-rwxr-xr-x 1 root root 908 Jun 17 00:47 appldata_mem.c.patch
-rwxr-xr-x 1 root root 11292 Jun 17 00:47 arlan-main.c.patch
-rwxr-xr-x 1 root root 4911 Jun 17 00:47 arlan-proc.c.patch
-rwxr-xr-x 1 root root 899 Jun 17 00:47 ash.c.patch
-rwxr-xr-x 1 root root 549 Jun 17 00:47 atari_NCR5380.c.patch
-rwxr-xr-x 1 root root 815 Jun 17 00:47 ati_remote.c.patch
-rwxr-xr-x 1 root root 442 Jun 17 00:47 atmel_read_eeprom.c.patch
-rwxr-xr-x 1 root root 860 Jun 17 00:47 atp870u.c.patch
-rwxr-xr-x 1 root root 1204 Jun 17 00:47 atyfb_base.c.patch
-rwxr-xr-x 1 root root 463 Jun 17 00:47 au88x0_eq.c.patch
-rwxr-xr-x 1 root root 444 Jun 17 00:47 auth_gss.c.patch
-rwxr-xr-x 1 root root 6581 Jun 17 00:47 av7110_av.c.patch
-rwxr-xr-x 1 root root 414 Jun 17 00:47 aztcd.c.patch
-rwxr-xr-x 1 root root 359 Jun 17 00:47 b44.c.patch
-rwxr-xr-x 1 root root 565 Jun 17 00:47 baycom_ser_fdx.c.patch
-rwxr-xr-x 1 root root 529 Jun 17 00:47 blacklist.c.patch
-rwxr-xr-x 1 root root 947 Jun 17 00:47 bond_main.c.patch
-rwxr-xr-x 1 root root 600 Jun 17 00:47 bt878.c.patch
-rwxr-xr-x 1 root root 503 Jun 17 00:47 bttv-cards.c.patch
-rwxr-xr-x 1 root root 883 Jun 17 00:47 bubinga.c.patch
-rwxr-xr-x 1 root root 769 Jun 17 00:47 cache.c.patch
-rwxr-xr-x 1 root root 1633 Jun 17 00:47 cciss.c.patch
-rwxr-xr-x 1 root root 773 Jun 17 00:47 cciss_scsi.c.patch
-rwxr-xr-x 1 root root 889 Jun 17 00:47 cifssmb.c.patch
-rwxr-xr-x 1 root root 24339 Jun 17 00:47 claw.c.patch
-rwxr-xr-x 1 root root 642 Jun 17 00:47 cls_u32.c.patch
-rwxr-xr-x 1 root root 1529 Jun 17 00:47 config.c.patch
-rwxr-xr-x 1 root root 614 Jun 17 00:47 conmakehash.c.patch
-rwxr-xr-x 1 root root 852 Jun 17 00:47 connect.c.patch
-rwxr-xr-x 1 root root 505 Jun 17 00:47 cpia.c.patch
-rwxr-xr-x 1 root root 480 Jun 17 00:47 cpia.h.patch
-rwxr-xr-x 1 root root 979 Jun 17 00:47 cpqarray.c.patch
-rwxr-xr-x 1 root root 1391 Jun 17 00:47 cpqfcTSinit.c.patch
-rwxr-xr-x 1 root root 523 Jun 17 00:47 cpqfcTSworker.c.patch
-rwxr-xr-x 1 root root 564 Jun 17 00:47 cpqphp.h.patch
-rwxr-xr-x 1 root root 1132 Jun 17 00:47 cpqphp_core.c.patch
-rwxr-xr-x 1 root root 1656 Jun 17 00:47 cpqphp_pci.c.patch
-rwxr-xr-x 1 root root 508 Jun 17 00:47 cpu.c.patch
-rwxr-xr-x 1 root root 4871 Jun 17 00:47 cs4281m.c.patch
-rwxr-xr-x 1 root root 6835 Jun 17 00:47 cs46xx.c.patch
-rwxr-xr-x 1 root root 477 Jun 17 00:47 ctcmain.c.patch
-rwxr-xr-x 1 root root 506 Jun 17 00:47 ctctty.c.patch
-rwxr-xr-x 1 root root 445 Jun 17 00:47 dac3550a.c.patch
-rwxr-xr-x 1 root root 455 Jun 17 00:47 daca.c.patch
-rwxr-xr-x 1 root root 660 Jun 17 00:47 dasd_proc.c.patch
-rwxr-xr-x 1 root root 556 Jun 17 00:47 dbdma.c.patch
-rwxr-xr-x 1 root root 1001 Jun 17 00:47 de4x5.c.patch
-rwxr-xr-x 1 root root 396 Jun 17 00:47 debug.c.patch
-rwxr-xr-x 1 root root 500 Jun 17 00:47 device_status.c.patch
-rwxr-xr-x 1 root root 564 Jun 17 00:47 divamnt.c.patch
-rwxr-xr-x 1 root root 519 Jun 17 00:47 divert_init.c.patch
-rwxr-xr-x 1 root root 1523 Jun 17 00:47 dpt_i2o.c.patch
-rwxr-xr-x 1 root root 2477 Jun 17 00:47 dst.c.patch
-rwxr-xr-x 1 root root 751 Jun 17 00:47 dst_ca.c.patch
-rwxr-xr-x 1 root root 833 Jun 17 00:47 e1000_hw.c.patch
-rwxr-xr-x 1 root root 755 Jun 17 00:47 eata_pio.c.patch
-rwxr-xr-x 1 root root 876 Jun 17 00:47 eepro.c.patch
-rwxr-xr-x 1 root root 553 Jun 17 00:47 eeprom.c.patch
-rwxr-xr-x 1 root root 471 Jun 17 00:47 efi.c.patch
-rwxr-xr-x 1 root root 427 Jun 17 00:47 eisa_enumerator.c.patch
-rwxr-xr-x 1 root root 442 Jun 17 00:47 erase.c.patch
-rwxr-xr-x 1 root root 602 Jun 17 00:47 es7000plat.c.patch
-rwxr-xr-x 1 root root 1177 Jun 17 00:47 exdump.c.patch
-rwxr-xr-x 1 root root 577 Jun 17 00:47 exnames.c.patch
-rwxr-xr-x 1 root root 483 Jun 17 00:47 exresop.c.patch
-rwxr-xr-x 1 root root 506 Jun 17 00:47 fault.c.patch
-rwxr-xr-x 1 root root 1060 Jun 17 00:47 fd1772.c.patch
-rwxr-xr-x 1 root root 1264 Jun 17 00:47 firestream.c.patch
-rwxr-xr-x 1 root root 396 Jun 17 00:47 fixup-rbtx4927.c.patch
-rwxr-xr-x 1 root root 462 Jun 17 00:47 flexcop-sram.c.patch
-rwxr-xr-x 1 root root 550 Jun 17 00:47 flexcop-usb.c.patch
-rwxr-xr-x 1 root root 835 Jun 17 00:47 forte.c.patch
-rwxr-xr-x 1 root root 730 Jun 17 00:47 fpga.c.patch
-rwxr-xr-x 1 root root 532 Jun 17 00:47 fplustm.c.patch
-rwxr-xr-x 1 root root 713 Jun 17 00:47 gdbinit.patch
-rwxr-xr-x 1 root root 502 Jun 17 00:47 gdth.c.patch
-rwxr-xr-x 1 root root 809 Jun 17 00:47 genex.S.patch
-rwxr-xr-x 1 root root 531 Jun 17 00:47 gss_krb5_seal.c.patch
-rwxr-xr-x 1 root root 452 Jun 17 00:47 gss_spkm3_token.c.patch
-rwxr-xr-x 1 root root 865 Jun 17 00:47 gus_mem.c.patch
-rwxr-xr-x 1 root root 410 Jun 17 00:47 hdpu.c.patch
-rwxr-xr-x 1 root root 1066 Jun 17 00:47 hfc_usb.c.patch
-rwxr-xr-x 1 root root 503 Jun 17 00:47 hgafb.c.patch
-rwxr-xr-x 1 root root 553 Jun 17 00:47 hil_mlc.c.patch
-rwxr-xr-x 1 root root 886 Jun 17 00:47 hysdn_init.c.patch
-rwxr-xr-x 1 root root 490 Jun 17 00:47 hysdn_sched.c.patch
-rwxr-xr-x 1 root root 1371 Jun 17 00:47 i2c-algo-ite.c.patch
-rwxr-xr-x 1 root root 935 Jun 17 00:47 i2c-i801.c.patch
-rwxr-xr-x 1 root root 577 Jun 17 00:47 i2c-piix4.c.patch
-rwxr-xr-x 1 root root 697 Jun 17 00:47 i2c-sis5595.c.patch
-rwxr-xr-x 1 root root 1558 Jun 17 00:47 i2o_proc.c.patch
-rwxr-xr-x 1 root root 2741 Jun 17 00:47 i82092.c.patch
-rwxr-xr-x 1 root root 610 Jun 17 00:47 iSeries_proc.c.patch
-rwxr-xr-x 1 root root 631 Jun 17 00:47 iSeries_setup.c.patch
-rwxr-xr-x 1 root root 1880 Jun 17 00:47 ibm_emac_debug.c.patch
-rwxr-xr-x 1 root root 1954 Jun 17 00:47 ibmphp_hpc.c.patch
-rwxr-xr-x 1 root root 507 Jun 17 00:47 ide-cd.c.patch
-rwxr-xr-x 1 root root 543 Jun 17 00:47 idt77252.c.patch
-rwxr-xr-x 1 root root 551 Jun 17 00:47 initio.c.patch
-rwxr-xr-x 1 root root 747 Jun 17 00:47 inode.c.patch
-rwxr-xr-x 1 root root 483 Jun 17 00:47 ip2main.c.patch
-rwxr-xr-x 1 root root 1214 Jun 17 00:47 ip6t_dst.c.patch
-rwxr-xr-x 1 root root 1214 Jun 17 00:47 ip6t_hbh.c.patch
-rwxr-xr-x 1 root root 488 Jun 17 00:47 ip_conntrack_standalone.c.patch
-rwxr-xr-x 1 root root 6600 Jun 17 00:47 iphase.c.patch
-rwxr-xr-x 1 root root 492 Jun 17 00:47 ipmi_bt_sm.c.patch
-rwxr-xr-x 1 root root 701 Jun 17 00:47 ips.c.patch
-rwxr-xr-x 1 root root 446 Jun 17 00:47 ircomm_param.c.patch
-rwxr-xr-x 1 root root 969 Jun 17 00:47 irda-usb.c.patch
-rwxr-xr-x 1 root root 392 Jun 17 00:47 irq.c-10337.patch
-rwxr-xr-x 1 root root 488 Jun 17 00:47 irq.c-9659.patch
-rwxr-xr-x 1 root root 498 Jun 17 00:47 irq.c.patch
-rwxr-xr-x 1 root root 1309 Jun 17 00:47 isdn_concap.c.patch
-rwxr-xr-x 1 root root 542 Jun 17 00:47 isdn_tty.c.patch
-rwxr-xr-x 1 root root 553 Jun 17 00:47 isdn_ttyfax.c.patch
-rwxr-xr-x 1 root root 2888 Jun 17 00:47 isdn_x25iface.c.patch
-rwxr-xr-x 1 root root 2718 Jun 17 00:47 islpci_dev.c.patch
-rwxr-xr-x 1 root root 1404 Jun 17 00:47 islpci_eth.c.patch
-rwxr-xr-x 1 root root 1612 Jun 17 00:47 islpci_mgt.c.patch
-rwxr-xr-x 1 root root 442 Jun 17 00:47 ixj.c.patch
-rwxr-xr-x 1 root root 623 Jun 17 00:47 jedec_probe.c.patch
-rwxr-xr-x 1 root root 499 Jun 17 00:47 jsm_tty.c.patch
-rwxr-xr-x 1 root root 292 Jun 17 00:47 kernel-doc.patch
-rwxr-xr-x 1 root root 9921 Jun 17 00:47 lanstreamer.c.patch
-rwxr-xr-x 1 root root 570 Jun 17 00:47 libata-core.c.patch
-rwxr-xr-x 1 root root 666 Jun 17 00:47 longhaul.c.patch
-rwxr-xr-x 1 root root 2280 Jun 17 00:47 lparcfg.c.patch
-rwxr-xr-x 1 root root 542 Jun 17 00:47 lpfc_scsi.c.patch
-rwxr-xr-x 1 root root 422 Jun 17 00:47 lpfc_sli.c.patch
-rwxr-xr-x 1 root root 576 Jun 17 00:47 m1535plus.c.patch
-rwxr-xr-x 1 root root 756 Jun 17 00:47 m32r_cfc.c.patch
-rwxr-xr-x 1 root root 477 Jun 17 00:47 mac_esp.c.patch
-rwxr-xr-x 1 root root 528 Jun 17 00:47 maple_pci.c.patch
-rwxr-xr-x 1 root root 661 Jun 17 00:47 math.c.patch
-rwxr-xr-x 1 root root 666 Jun 17 00:47 mcdx.c.patch
-rwxr-xr-x 1 root root 1578 Jun 17 00:47 mconsole_kern.c.patch
-rwxr-xr-x 1 root root 434 Jun 17 00:47 md.c.patch
-rwxr-xr-x 1 root root 449 Jun 17 00:47 mdc800.c.patch
-rwxr-xr-x 1 root root 949 Jun 17 00:47 microcode.c.patch
-rwxr-xr-x 1 root root 399 Jun 17 00:47 mkprep.c.patch
-rwxr-xr-x 1 root root 698 Jun 17 00:47 mpic.c.patch
-rwxr-xr-x 1 root root 607 Jun 17 00:47 mpparse.c.patch
-rwxr-xr-x 1 root root 3380 Jun 17 00:47 mptbase.c.patch
-rwxr-xr-x 1 root root 3183 Jun 17 00:47 mptctl.c.patch
-rwxr-xr-x 1 root root 3303 Jun 17 00:47 mptscsih.c.patch
-rwxr-xr-x 1 root root 490 Jun 17 00:47 mtpav.c.patch
-rwxr-xr-x 1 root root 1481 Jun 17 00:47 mv643xx_eth.c.patch
-rwxr-xr-x 1 root root 642 Jun 17 00:47 nand_base.c.patch
-rwxr-xr-x 1 root root 488 Jun 17 00:47 nfs4renewd.c.patch
-rwxr-xr-x 1 root root 453 Jun 17 00:47 nfsproc.c.patch
-rwxr-xr-x 1 root root 5954 Jun 17 00:47 nicstar.c.patch
-rwxr-xr-x 1 root root 896 Jun 17 00:47 nodelist.c.patch
-rwxr-xr-x 1 root root 407 Jun 17 00:47 nsaccess.c.patch
-rwxr-xr-x 1 root root 481 Jun 17 00:47 nsnames.c.patch
-rwxr-xr-x 1 root root 13767 Jun 17 00:47 olympic.c.patch
-rwxr-xr-x 1 root root 478 Jun 17 00:47 omap_udc.c.patch
-rwxr-xr-x 1 root root 419 Jun 17 00:47 parport_amiga.c.patch
-rwxr-xr-x 1 root root 433 Jun 17 00:47 parport_mfc3.c.patch
-rwxr-xr-x 1 root root 417 Jun 17 00:47 pci_link.c.patch
-rwxr-xr-x 1 root root 2319 Jun 17 00:47 pciehp_hpc.c.patch
-rwxr-xr-x 1 root root 511 Jun 17 00:47 pciehp_pci.c.patch
-rwxr-xr-x 1 root root 642 Jun 17 00:47 pcmplc.c.patch
-rwxr-xr-x 1 root root 883 Jun 17 00:47 perfmon.c.patch
-rwxr-xr-x 1 root root 382 Jun 17 00:47 piggyback.c.patch
-rwxr-xr-x 1 root root 586 Jun 17 00:47 pktgen.c.patch
-rwxr-xr-x 1 root root 3349 Jun 17 00:47 pm.c.patch
-rwxr-xr-x 1 root root 348 Jun 17 00:47 ppc4xx_kgdb.c.patch
-rwxr-xr-x 1 root root 443 Jun 17 00:47 ppc4xx_sgdma.c.patch
-rwxr-xr-x 1 root root 485 Jun 17 00:47 proxy.c.patch
-rwxr-xr-x 1 root root 441 Jun 17 00:47 pt.c.patch
-rwxr-xr-x 1 root root 507 Jun 17 00:47 pxa27x.c.patch
-rwxr-xr-x 1 root root 507 Jun 17 00:47 q40ints.c.patch
-rwxr-xr-x 1 root root 808 Jun 17 00:47 q931.c.patch
-rwxr-xr-x 1 root root 1894 Jun 17 00:47 qeth_main.c.patch
-rwxr-xr-x 1 root root 3912 Jun 17 00:47 qla1280.c.patch
-rwxr-xr-x 1 root root 1079 Jun 17 00:47 qla_dbg.c.patch
-rwxr-xr-x 1 root root 489 Jun 17 00:47 qla_init.c.patch
-rwxr-xr-x 1 root root 1800 Jun 17 00:47 qlogicfc.c.patch
-rwxr-xr-x 1 root root 1094 Jun 17 00:47 qlogicisp.c.patch
-rwxr-xr-x 1 root root 508 Jun 17 00:47 raid1.c.patch
-rwxr-xr-x 1 root root 512 Jun 17 00:47 raid10.c.patch
-rwxr-xr-x 1 root root 789 Jun 17 00:47 raw1394.c.patch
-rwxr-xr-x 1 root root 2275 Jun 17 00:47 ray_cs.c.patch
-rwxr-xr-x 1 root root 427 Jun 17 00:47 rioboot.c.patch
-rwxr-xr-x 1 root root 530 Jun 17 00:47 rioinit.c.patch
-rwxr-xr-x 1 root root 400 Jun 17 00:47 riointr.c.patch
-rwxr-xr-x 1 root root 2022 Jun 17 00:47 riotty.c.patch
-rwxr-xr-x 1 root root 429 Jun 17 00:47 rndis.c.patch
-rwxr-xr-x 1 root root 1007 Jun 17 00:47 rocket.c.patch
-rwxr-xr-x 1 root root 471 Jun 17 00:47 route.c.patch
-rwxr-xr-x 1 root root 560 Jun 17 00:47 rpaphp_pci.c.patch
-rwxr-xr-x 1 root root 479 Jun 17 00:47 rpc_pipe.c.patch
-rwxr-xr-x 1 root root 616 Jun 17 00:47 rtas.c.patch
-rwxr-xr-x 1 root root 752 Jun 17 00:47 s2io.c.patch
-rwxr-xr-x 1 root root 465 Jun 17 00:47 sc1200.c.patch
-rwxr-xr-x 1 root root 455 Jun 17 00:47 sch_ingress.c.patch
-rwxr-xr-x 1 root root 1148 Jun 17 00:47 script_asm.pl.patch
-rwxr-xr-x 1 root root 477 Jun 17 00:47 scsi.c.patch
-rwxr-xr-x 1 root root 459 Jun 17 00:47 scsicam.c.patch
-rwxr-xr-x 1 root root 1513 Jun 17 00:47 sd.c.patch
-rwxr-xr-x 1 root root 507 Jun 17 00:47 sdla.c.patch
-rwxr-xr-x 1 root root 573 Jun 17 00:47 sdla_chdlc.c.patch
-rwxr-xr-x 1 root root 1015 Jun 17 00:47 sdla_fr.c.patch
-rwxr-xr-x 1 root root 503 Jun 17 00:47 sdla_ppp.c.patch
-rwxr-xr-x 1 root root 1170 Jun 17 00:47 sdla_x25.c.patch
-rwxr-xr-x 1 root root 784 Jun 17 00:47 sdladrv.c.patch
-rwxr-xr-x 1 root root 1683 Jun 17 00:47 seagate.c.patch
-rwxr-xr-x 1 root root 419 Jun 17 00:47 seq_fifo.c.patch
-rwxr-xr-x 1 root root 456 Jun 17 00:47 seq_timer.c.patch
-rwxr-xr-x 1 root root 428 Jun 17 00:47 setup.c-20555.patch
-rwxr-xr-x 1 root root 451 Jun 17 00:47 setup.c-30769.patch
-rwxr-xr-x 1 root root 1025 Jun 17 00:47 setup.c.patch
-rwxr-xr-x 1 root root 458 Jun 17 00:47 sg.c.patch
-rwxr-xr-x 1 root root 467 Jun 17 00:47 shpchprm_legacy.c.patch
-rwxr-xr-x 1 root root 977 Jun 17 00:47 sis5513.c.patch
-rwxr-xr-x 1 root root 837 Jun 17 00:47 sis900.c.patch
-rwxr-xr-x 1 root root 789 Jun 17 00:47 sk_g16.c.patch
-rwxr-xr-x 1 root root 474 Jun 17 00:47 skgesirq.c.patch
-rwxr-xr-x 1 root root 2750 Jun 17 00:47 skystar2.c.patch
-rwxr-xr-x 1 root root 6627 Jun 17 00:47 smc9194.c.patch
-rwxr-xr-x 1 root root 462 Jun 17 00:47 smc91x.c.patch
-rwxr-xr-x 1 root root 927 Jun 17 00:47 smtparse.c.patch
-rwxr-xr-x 1 root root 1671 Jun 17 00:47 specialix.c.patch
-rwxr-xr-x 1 root root 642 Jun 17 00:47 speedstep-centrino.c.patch
-rwxr-xr-x 1 root root 571 Jun 17 00:47 srf.c.patch
-rwxr-xr-x 1 root root 448 Jun 17 00:47 sstfb.c.patch
-rwxr-xr-x 1 root root 953 Jun 17 00:47 stallion.c.patch
-rwxr-xr-x 1 root root 537 Jun 17 00:47 stx_gp3.c.patch
-rwxr-xr-x 1 root root 547 Jun 17 00:47 sun3_NCR5380.c.patch
-rwxr-xr-x 1 root root 598 Jun 17 00:47 superio.c.patch
-rwxr-xr-x 1 root root 554 Jun 17 00:47 svclock.c.patch
-rwxr-xr-x 1 root root 2668 Jun 17 00:47 swarm_cs4297a.c.patch
-rwxr-xr-x 1 root root 1231 Jun 17 00:47 sx.c.patch
-rwxr-xr-x 1 root root 885 Jun 17 00:47 sycamore.c.patch
-rwxr-xr-x 1 root root 450 Jun 17 00:47 sys_dp264.c.patch
-rwxr-xr-x 1 root root 458 Jun 17 00:47 sys_titan.c.patch
-rwxr-xr-x 1 root root 430 Jun 17 00:47 sysrq.c.patch
-rwxr-xr-x 1 root root 1619 Jun 17 00:47 system.h.patch
-rwxr-xr-x 1 root root 690 Jun 17 00:47 tape_core.c.patch
-rwxr-xr-x 1 root root 1267 Jun 17 00:47 tas_common.h.patch
-rwxr-xr-x 1 root root 450 Jun 17 00:47 tbrsdt.c.patch
-rwxr-xr-x 1 root root 470 Jun 17 00:47 tbxfroot.c.patch
-rwxr-xr-x 1 root root 502 Jun 17 00:47 tg3.c.patch
-rwxr-xr-x 1 root root 503 Jun 17 00:47 therm_adt746x.c.patch
-rwxr-xr-x 1 root root 730 Jun 17 00:47 timer_tsc.c.patch
-rwxr-xr-x 1 root root 633 Jun 17 00:47 tlan.c.patch
-rwxr-xr-x 1 root root 743 Jun 17 00:47 tms380tr.c.patch
-rwxr-xr-x 1 root root 896 Jun 17 00:47 tmscsim.c.patch
-rwxr-xr-x 1 root root 531 Jun 17 00:47 toshiba_rbtx4927_setup.c.patch
-rwxr-xr-x 1 root root 422 Jun 17 00:47 tpm.c.patch
-rwxr-xr-x 1 root root 502 Jun 17 00:47 tqm8xxl.c.patch
-rwxr-xr-x 1 root root 471 Jun 17 00:47 traps.c-26038.patch
-rwxr-xr-x 1 root root 508 Jun 17 00:47 traps.c.patch
-rwxr-xr-x 1 root root 425 Jun 17 00:47 tumbler.c.patch
-rwxr-xr-x 1 root root 1910 Jun 17 00:47 tx4927_irq.c.patch
-rwxr-xr-x 1 root root 1906 Jun 17 00:47 usX2Yhwdep.c.patch
-rwxr-xr-x 1 root root 486 Jun 17 00:47 usbusx2yaudio.c.patch
-rwxr-xr-x 1 root root 360 Jun 17 00:47 virgefb.c.patch
-rwxr-xr-x 1 root root 418 Jun 17 00:47 vlan.c.patch
-rwxr-xr-x 1 root root 646 Jun 17 00:47 vlsi_ir.c.patch
-rwxr-xr-x 1 root root 485 Jun 17 00:47 vmlogrdr.c.patch
-rwxr-xr-x 1 root root 467 Jun 17 00:47 vx_pcm.c.patch
-rwxr-xr-x 1 root root 431 Jun 17 00:47 wakeup.c.patch
-rwxr-xr-x 1 root root 881 Jun 17 00:47 walnut.c.patch
-rwxr-xr-x 1 root root 583 Jun 17 00:47 wanpipe_multppp.c.patch
-rwxr-xr-x 1 root root 634 Jun 17 00:47 wireless.c.patch
-rwxr-xr-x 1 root root 583 Jun 17 00:47 xfs_bmap.c.patch
-rwxr-xr-x 1 root root 2245 Jun 17 00:47 xfs_iomap.c.patch
-rwxr-xr-x 1 root root 440 Jun 17 00:47 xics.c.patch
-rwxr-xr-x 1 root root 3304 Jun 17 00:47 xircom_cb.c.patch
-rwxr-xr-x 1 root root 1726 Jun 17 00:47 xmon.c-23101.patch
-rwxr-xr-x 1 root root 385 Jun 17 00:47 xmon.c.patch
-rwxr-xr-x 1 root root 944 Jun 17 00:47 xpram.c.patch
-rwxr-xr-x 1 root root 499 Jun 17 00:47 zoran_procfs.c.patch
--
vda
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 6:58 ` cutaway
@ 2005-06-21 11:02 ` Denis Vlasenko
2005-06-21 13:08 ` cutaway
0 siblings, 1 reply; 19+ messages in thread
From: Denis Vlasenko @ 2005-06-21 11:02 UTC (permalink / raw)
To: cutaway, Jesper Juhl, linux-kernel
Cc: Andrew Morton, Jeff Garzik, Domen Puncer
On Tuesday 21 June 2005 09:58, cutaway@bellsouth.net wrote:
> Examine each case individually...
>
> Any code that did a "sizeof(foo)" is [very] likely to give different
> results.
>
> Also, if there are several instances of "foo" being passed around as
> parameter, you may find the generated code gets somewhat worse if "foo" used
> to be a stack based autovar. On x86, the const[] implementation will always
> cause a 5 byte PUSH for a parameter, whereas the autovar pointer
> implementation often will be a shorter 3 byte EBP relative push. With many
> instances of 'foo' usage (or used in a loop), you may be better off paying
> the price of an autovar init during prolog to get the cheaper parm pushes
> later.
But that 3 byte push is fetching data from stack, while 5 byte const push
does not. I ike smaller code, but not _this_ much.
Also this smallish size advantage may be i386-specific only.
--
vda
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 13:08 ` cutaway
@ 2005-06-21 13:06 ` Denis Vlasenko
2005-06-21 14:38 ` cutaway
2005-06-21 13:20 ` Denis Vlasenko
1 sibling, 1 reply; 19+ messages in thread
From: Denis Vlasenko @ 2005-06-21 13:06 UTC (permalink / raw)
To: cutaway, Jesper Juhl, linux-kernel
Cc: Andrew Morton, Jeff Garzik, Domen Puncer
On Tuesday 21 June 2005 16:08, cutaway@bellsouth.net wrote:
> Memory is memory. Pushed from the stack or as a 4 byte immediate value you
> still have to get those 4 bytes somewhere although with the pointer you DO
> actually stand a chance GCC might enregister the pointer variable.
>
> Sure you don't think instruction bytes fetching is free ;->
I think that instruction fetch is deeply prefetched, thus
push immediate
do not need to wait for operand, no AGU to allocate, nothing,
while
push N(%ebp)
depends on %ebp value, on (%ebp+N) value, will need AGU.
> BTW, I don't give a shit about the size advantage. Put the 3 byte EBP ref
> and the 5 byte push imm32 in a loop and measure them - I know what the
> answer will be.
You know wrong.
# cat t.c
#define rdtscl(low) asm volatile("rdtsc" : "=a" (low) : : "edx")
#define NL "\n"
#include <stdio.h>
int main() {
int i,k,start,end;
int v = 1234;
for(k=0; k<6; k++) {
rdtscl(start);
for(i=0; i<1000; i++) {
asm(NL
" push %0" NL
" pop %%eax" NL
" push %0" NL
" pop %%eax" NL
" push %0" NL
" pop %%eax" NL
" push %0" NL
" pop %%eax" NL
: /* outputs */
: "m" (v) /* inputs */
: "ax" /* clobbers */
);
}
rdtscl(end);
printf("Took %u CPU cycles ", end-start);
rdtscl(start);
for(i=0; i<1000; i++) {
asm(NL
" push %%ebx" NL
" pop %%eax" NL
" push %%ebx" NL
" pop %%eax" NL
" push %%ebx" NL
" pop %%eax" NL
" push %%ebx" NL
" pop %%eax" NL
: /* outputs */
: /* inputs */
: "ax" /* clobbers */
);
}
rdtscl(end);
printf("Took %u CPU cycles\n", end-start);
}
return 0;
}
# gcc -O2 -falign-loops=64 t.c
# ./a.out
Took 9574 CPU cycles Took 8068 CPU cycles
Took 9575 CPU cycles Took 8058 CPU cycles
Took 9134 CPU cycles Took 8061 CPU cycles
Took 9134 CPU cycles Took 8043 CPU cycles
Took 9134 CPU cycles Took 8043 CPU cycles
Took 9134 CPU cycles Took 8043 CPU cycles
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 11
model name : Intel(R) Celeron(TM) CPU 1200MHz
stepping : 1
cpu MHz : 1196.207
cache size : 256 KB
physical id : 0
siblings : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 2359.29
# gcc -O2 -falign-loops=64 -c t.c
# objdump -d -r t.o
t.o: file format elf32-i386
Disassembly of section .text:
00000000 <main>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 53 push %ebx
4: 50 push %eax
5: 83 e4 f0 and $0xfffffff0,%esp
8: 83 ec 10 sub $0x10,%esp
b: c7 45 f8 d2 04 00 00 movl $0x4d2,0xfffffff8(%ebp)
12: 31 db xor %ebx,%ebx
14: 0f 31 rdtsc
16: ba e7 03 00 00 mov $0x3e7,%edx
1b: 89 c1 mov %eax,%ecx
1d: 90 nop
1e: 90 nop
1f: 90 nop
20: 90 nop
21: 90 nop
22: 90 nop
23: 90 nop
24: 90 nop
25: 90 nop
26: 90 nop
27: 90 nop
28: 90 nop
29: 90 nop
2a: 90 nop
2b: 90 nop
2c: 90 nop
2d: 90 nop
2e: 90 nop
2f: 90 nop
30: 90 nop
31: 90 nop
32: 90 nop
33: 90 nop
34: 90 nop
35: 90 nop
36: 90 nop
37: 90 nop
38: 90 nop
39: 90 nop
3a: 90 nop
3b: 90 nop
3c: 90 nop
3d: 90 nop
3e: 90 nop
3f: 90 nop
40: ff 75 f8 pushl 0xfffffff8(%ebp)
43: 58 pop %eax
44: ff 75 f8 pushl 0xfffffff8(%ebp)
47: 58 pop %eax
48: ff 75 f8 pushl 0xfffffff8(%ebp)
4b: 58 pop %eax
4c: ff 75 f8 pushl 0xfffffff8(%ebp)
4f: 58 pop %eax
50: 4a dec %edx
51: 79 ed jns 40 <main+0x40>
53: 0f 31 rdtsc
55: 83 ec 08 sub $0x8,%esp
58: 29 c8 sub %ecx,%eax
5a: 50 push %eax
5b: 68 00 00 00 00 push $0x0
5c: R_386_32 .rodata.str1.1
60: e8 fc ff ff ff call 61 <main+0x61>
61: R_386_PC32 printf
65: 0f 31 rdtsc
67: ba e7 03 00 00 mov $0x3e7,%edx
6c: 89 c1 mov %eax,%ecx
6e: 83 c4 10 add $0x10,%esp
71: eb 0d jmp 80 <main+0x80>
73: 90 nop
74: 90 nop
75: 90 nop
76: 90 nop
77: 90 nop
78: 90 nop
79: 90 nop
7a: 90 nop
7b: 90 nop
7c: 90 nop
7d: 90 nop
7e: 90 nop
7f: 90 nop
80: 53 push %ebx
81: 58 pop %eax
82: 53 push %ebx
83: 58 pop %eax
84: 53 push %ebx
85: 58 pop %eax
86: 53 push %ebx
87: 58 pop %eax
88: 4a dec %edx
89: 79 f5 jns 80 <main+0x80>
8b: 0f 31 rdtsc
8d: 83 ec 08 sub $0x8,%esp
90: 29 c8 sub %ecx,%eax
92: 50 push %eax
93: 68 14 00 00 00 push $0x14
94: R_386_32 .rodata.str1.1
98: 43 inc %ebx
99: e8 fc ff ff ff call 9a <main+0x9a>
9a: R_386_PC32 printf
9e: 83 c4 10 add $0x10,%esp
a1: 83 fb 05 cmp $0x5,%ebx
a4: 0f 8e 6a ff ff ff jle 14 <main+0x14>
aa: 31 c0 xor %eax,%eax
ac: 8b 5d fc mov 0xfffffffc(%ebp),%ebx
af: c9 leave
b0: c3 ret
--
vda
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 11:02 ` Denis Vlasenko
@ 2005-06-21 13:08 ` cutaway
2005-06-21 13:06 ` Denis Vlasenko
2005-06-21 13:20 ` Denis Vlasenko
0 siblings, 2 replies; 19+ messages in thread
From: cutaway @ 2005-06-21 13:08 UTC (permalink / raw)
To: Denis Vlasenko, Jesper Juhl, linux-kernel
Cc: Andrew Morton, Jeff Garzik, Domen Puncer
Memory is memory. Pushed from the stack or as a 4 byte immediate value you
still have to get those 4 bytes somewhere although with the pointer you DO
actually stand a chance GCC might enregister the pointer variable.
Sure you don't think instruction bytes fetching is free ;->
BTW, I don't give a shit about the size advantage. Put the 3 byte EBP ref
and the 5 byte push imm32 in a loop and measure them - I know what the
answer will be.
----- Original Message -----
From: "Denis Vlasenko" <vda@ilport.com.ua>
To: <cutaway@bellsouth.net>; "Jesper Juhl" <juhl-lkml@dif.dk>;
"linux-kernel" <linux-kernel@vger.kernel.org>
>
> But that 3 byte push is fetching data from stack, while 5 byte const push
> does not. I ike smaller code, but not _this_ much.
>
> Also this smallish size advantage may be i386-specific only.
> --
> vda
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 13:08 ` cutaway
2005-06-21 13:06 ` Denis Vlasenko
@ 2005-06-21 13:20 ` Denis Vlasenko
1 sibling, 0 replies; 19+ messages in thread
From: Denis Vlasenko @ 2005-06-21 13:20 UTC (permalink / raw)
To: cutaway, Jesper Juhl, linux-kernel
Cc: Andrew Morton, Jeff Garzik, Domen Puncer
Um, prev one was using push %reg. My fault.
push $imm gives the same result:
# gcc -O2 -falign-loops=64 t.c
# ./a.out
Took 9291 CPU cycles Took 8068 CPU cycles
Took 9080 CPU cycles Took 8058 CPU cycles
Took 9134 CPU cycles Took 8061 CPU cycles
Took 9084 CPU cycles Took 8043 CPU cycles
Took 9084 CPU cycles Took 8043 CPU cycles
Took 9084 CPU cycles Took 8043 CPU cycles
The source:
#define rdtscl(low) asm volatile("rdtsc" : "=a" (low) : : "edx")
#define NL "\n"
#include <stdio.h>
int main() {
int i,k,start,end;
int v = 1234;
for(k=0; k<6; k++) {
rdtscl(start);
for(i=0; i<1000; i++) {
asm(NL
" push %0" NL
" pop %%eax" NL
" push %0" NL
" pop %%eax" NL
" push %0" NL
" pop %%eax" NL
" push %0" NL
" pop %%eax" NL
: /* outputs */
: "m" (v) /* inputs */
: "ax" /* clobbers */
);
}
rdtscl(end);
printf("Took %u CPU cycles ", end-start);
rdtscl(start);
for(i=0; i<1000; i++) {
asm(NL
" push $1234" NL
" pop %%eax" NL
" push $1234" NL
" pop %%eax" NL
" push $1234" NL
" pop %%eax" NL
" push $1234" NL
" pop %%eax" NL
: /* outputs */
: /* inputs */
: "ax" /* clobbers */
);
}
rdtscl(end);
printf("Took %u CPU cycles\n", end-start);
}
return 0;
}
--
vda
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 14:38 ` cutaway
@ 2005-06-21 13:52 ` Denis Vlasenko
0 siblings, 0 replies; 19+ messages in thread
From: Denis Vlasenko @ 2005-06-21 13:52 UTC (permalink / raw)
To: cutaway, Jesper Juhl, linux-kernel
Cc: Andrew Morton, Jeff Garzik, Domen Puncer
On Tuesday 21 June 2005 17:38, cutaway@bellsouth.net wrote:
> Congratulations, you proved that a register push is faster than a 3 byte
> memory push. I believe this is exactly what I said would happen if the
> autovar pointer wound up being enregistered.
>
> However, it is NOT what GCC will generate for pushing params to static
> strings.
>
> For that you're going to get a 5 byte PUSH imm32.
My fault, I already mailed the corrected program.
Please see it. Now please admit you were wrong.
--
vda
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 13:06 ` Denis Vlasenko
@ 2005-06-21 14:38 ` cutaway
2005-06-21 13:52 ` Denis Vlasenko
0 siblings, 1 reply; 19+ messages in thread
From: cutaway @ 2005-06-21 14:38 UTC (permalink / raw)
To: Denis Vlasenko, Jesper Juhl, linux-kernel
Cc: Andrew Morton, Jeff Garzik, Domen Puncer
Congratulations, you proved that a register push is faster than a 3 byte
memory push. I believe this is exactly what I said would happen if the
autovar pointer wound up being enregistered.
However, it is NOT what GCC will generate for pushing params to static
strings.
For that you're going to get a 5 byte PUSH imm32.
----- Original Message -----
From: "Denis Vlasenko" <vda@ilport.com.ua>
To: <cutaway@bellsouth.net>; "Jesper Juhl" <juhl-lkml@dif.dk>;
"linux-kernel" <linux-kernel@vger.kernel.org>
Cc: "Andrew Morton" <akpm@osdl.org>; "Jeff Garzik" <jgarzik@pobox.com>;
"Domen Puncer" <domen@coderock.org>
Sent: Tuesday, June 21, 2005 09:06
Subject: Re: [RFC] cleanup patches for strings
Took 9574 CPU cycles Took 8068 CPU cycles
> 40: ff 75 f8 pushl 0xfffffff8(%ebp)
> 43: 58 pop %eax
> 80: 53 push %ebx
> 81: 58 pop %eax
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 9:31 ` Jörn Engel
@ 2005-06-21 20:47 ` Jesper Juhl
0 siblings, 0 replies; 19+ messages in thread
From: Jesper Juhl @ 2005-06-21 20:47 UTC (permalink / raw)
To: linux-kernel
Cc: Alexey Dobriyan, Jesper Juhl, Andrew Morton, Jeff Garzik,
Domen Puncer, Andrey Panin, cutaway, Denis Vlasenko,
Jörn Engel
Thanks for all the input guys. I guess submitting all these in a big
bunch is not such a good thing after all.. Probably a careful
evaluation of each one and a slow trickle of patches over time will be
better.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-20 22:46 [RFC] cleanup patches for strings Jesper Juhl
` (3 preceding siblings ...)
2005-06-21 10:59 ` Denis Vlasenko
@ 2005-06-21 21:12 ` Horst von Brand
4 siblings, 0 replies; 19+ messages in thread
From: Horst von Brand @ 2005-06-21 21:12 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel, Andrew Morton, Jeff Garzik, Domen Puncer
Jesper Juhl <juhl-lkml@dif.dk> wrote:
> I have a bunch (few hundred) of oneliners like the ones below lying around
> on my HD and I'm wondering what the best way to submit them is.
>
> The patches all make the same change, there's just a lot of files the
> change needs to be made in. The change they make is to change strings
> from the form
> [const] char *foo = "blah";
> to
> [const] char foo[] = "blah";
>
> The reason to do this was well explained by Jeff Garzik in the past (and
> now found in the Kernel Janitors TODO) :
Which is dead wrong. A short test program here (Fedora rawhide, i686,
gcc-4.0.0) shows that if you use an array, it is allocated on the stack and
the contents of the (constant, readonly) string is copied there before use,
just as you'd have to expect given C's semantics. I.e., the function gets
larger, slower, and uses more stack. If the array is declared const makes
no difference (AFAIR, it can't, as the const doesn't guarantee it won't be
changed).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 10:59 ` Denis Vlasenko
@ 2005-06-21 21:24 ` Jean Delvare
2005-06-21 22:33 ` cutaway
0 siblings, 1 reply; 19+ messages in thread
From: Jean Delvare @ 2005-06-21 21:24 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: LKML
Hi Denis,
> I have 361813 bytes in 292 patches for:
>
> - printk(KERN_ERR "%s: start receive command failed \n", dev->name);
> + printk(KERN_ERR "%s: start receive command failed\n", dev->name);
>
> type patches. Are these needed?
I think so. I can't think of a more useless way to waste memory ;)
> In case you wonder whether YOUR driver has such things, the list:
Could you send me a patch grouping all patches affecting drivers under
drivers/i2c (and possibly include/linux/i2c* files)? I'll get them
merged.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 22:33 ` cutaway
@ 2005-06-21 21:49 ` Jean Delvare
2005-06-21 23:11 ` cutaway
0 siblings, 1 reply; 19+ messages in thread
From: Jean Delvare @ 2005-06-21 21:49 UTC (permalink / raw)
To: cutaway; +Cc: Denis Vlasenko, LKML
Hi,... hm, don't you have a name?
> Jean, the default string alignments GCC seems to insist on using are
> going to screw you far more than the extra byte here or there ;->
That's possible, however I can't do anything against GCC personally,
while I can help cleanup the code and possibly actually space a few
bytes here and there. So let's just do it.
Oh, and GCC might end up being smart, who knows.
--
Jean Delvare
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 21:24 ` Jean Delvare
@ 2005-06-21 22:33 ` cutaway
2005-06-21 21:49 ` Jean Delvare
0 siblings, 1 reply; 19+ messages in thread
From: cutaway @ 2005-06-21 22:33 UTC (permalink / raw)
To: Jean Delvare, Denis Vlasenko; +Cc: LKML
Jean, the default string alignments GCC seems to insist on using are going
to screw you far more than the extra byte here or there ;->
I've measured close to 100K+ of fluff 0x00 pad bytes in a 2.6 kernel that
are due to GCC. FWIW, a while ago I posted a small utility to measure this
grotesque wastage.
----- Original Message -----
From: "Jean Delvare" <khali@linux-fr.org>
To: "Denis Vlasenko" <vda@ilport.com.ua>
Cc: "LKML" <linux-kernel@vger.kernel.org>
Sent: Tuesday, June 21, 2005 17:24
Subject: Re: [RFC] cleanup patches for strings
>
> I think so. I can't think of a more useless way to waste memory ;)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 21:49 ` Jean Delvare
@ 2005-06-21 23:11 ` cutaway
2005-06-22 0:16 ` Brian Gerst
0 siblings, 1 reply; 19+ messages in thread
From: cutaway @ 2005-06-21 23:11 UTC (permalink / raw)
To: Jean Delvare; +Cc: Denis Vlasenko, LKML
There is a way to defeat the GCC string alignments by putting the strings in
a dynamically sized structure if anyone cares. A bonus side effect of this
scheme is that kernel/driver NLS translations would become almost trivial
because all the string texts are collected in one place.
The basic idea looks like this:
#define MSG1 "Message text blah"
#define MSG2 "Message text blah, blah"
#define MSG3 "Message text blah, blah, blah"
#ifndef __GCC_FORMAT_STRING_CHECKS__
static const struct
{
char m1[sizeof(MSG1)+1];
char m2[sizeof(MSG2)+1];
char m3[sizeof(MSG3)+1];
} msg = {
{MSG1},
{MSG2},
{MSG3}
};
#undef MSG1
#undef MSG2
#undef MSG3
#define MSG1 msg.m1
#define MSG2 msg.m2
#define MSG3 msg.m3
#endif
The #ifdef allows for a "trial build" so GCC can type match parms to format
strings by just plugging the texts in verbatim like it is today.
The next logical step up from this would be to extract the #define "...."
stuff into a header, and voila, you've got trivial kernel/driver translation
(at least for pan-euro/western languages) essentially for free that doesn't
require anyone to fork off a special translation tree - they can keep using
mainline code base and just do a language specific header translation.
This scheme has saved several hundreds of bytes in couple of drivers I've
been diddling around with prototyping some changes on.
(Name == Tony Ingenoso)
----- Original Message -----
From: "Jean Delvare" <khali@linux-fr.org>
To: <cutaway@bellsouth.net>
Cc: "Denis Vlasenko" <vda@ilport.com.ua>; "LKML"
<linux-kernel@vger.kernel.org>
Sent: Tuesday, June 21, 2005 17:49
Subject: Re: [RFC] cleanup patches for strings
> Hi,... hm, don't you have a name?
>
> > Jean, the default string alignments GCC seems to insist on using are
> > going to screw you far more than the extra byte here or there ;->
>
> That's possible, however I can't do anything against GCC personally,
> while I can help cleanup the code and possibly actually space a few
> bytes here and there. So let's just do it.
>
> Oh, and GCC might end up being smart, who knows.
>
> --
> Jean Delvare
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC] cleanup patches for strings
2005-06-21 23:11 ` cutaway
@ 2005-06-22 0:16 ` Brian Gerst
0 siblings, 0 replies; 19+ messages in thread
From: Brian Gerst @ 2005-06-22 0:16 UTC (permalink / raw)
To: cutaway; +Cc: Jean Delvare, Denis Vlasenko, LKML
cutaway@bellsouth.net wrote:
> There is a way to defeat the GCC string alignments by putting the strings in
> a dynamically sized structure if anyone cares. A bonus side effect of this
> scheme is that kernel/driver NLS translations would become almost trivial
> because all the string texts are collected in one place.
>
> The basic idea looks like this:
>
> #define MSG1 "Message text blah"
> #define MSG2 "Message text blah, blah"
> #define MSG3 "Message text blah, blah, blah"
>
> #ifndef __GCC_FORMAT_STRING_CHECKS__
> static const struct
> {
> char m1[sizeof(MSG1)+1];
> char m2[sizeof(MSG2)+1];
> char m3[sizeof(MSG3)+1];
> } msg = {
> {MSG1},
> {MSG2},
> {MSG3}
> };
> #undef MSG1
> #undef MSG2
> #undef MSG3
> #define MSG1 msg.m1
> #define MSG2 msg.m2
> #define MSG3 msg.m3
> #endif
>
Sometimes the cure is worse than the disease.
--
Brian Gerst
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2005-06-22 0:18 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-20 22:46 [RFC] cleanup patches for strings Jesper Juhl
2005-06-21 6:58 ` cutaway
2005-06-21 11:02 ` Denis Vlasenko
2005-06-21 13:08 ` cutaway
2005-06-21 13:06 ` Denis Vlasenko
2005-06-21 14:38 ` cutaway
2005-06-21 13:52 ` Denis Vlasenko
2005-06-21 13:20 ` Denis Vlasenko
2005-06-21 8:59 ` Alexey Dobriyan
2005-06-21 9:31 ` Jörn Engel
2005-06-21 20:47 ` Jesper Juhl
2005-06-21 9:04 ` Andrey Panin
2005-06-21 10:59 ` Denis Vlasenko
2005-06-21 21:24 ` Jean Delvare
2005-06-21 22:33 ` cutaway
2005-06-21 21:49 ` Jean Delvare
2005-06-21 23:11 ` cutaway
2005-06-22 0:16 ` Brian Gerst
2005-06-21 21:12 ` Horst von Brand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox