From: Andrey Panin <pazke@donpac.ru>
To: Jesper Juhl <juhl-lkml@dif.dk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] cleanup patches for strings
Date: Tue, 21 Jun 2005 13:04:42 +0400 [thread overview]
Message-ID: <20050621090442.GD18900@pazke> (raw)
In-Reply-To: <Pine.LNX.4.62.0506200052320.2415@dragon.hyggekrogen.localhost>
[-- 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 --]
next prev parent reply other threads:[~2005-06-21 9:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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=20050621090442.GD18900@pazke \
--to=pazke@donpac.ru \
--cc=juhl-lkml@dif.dk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.