[PATCH] Have split-include take another argument

[PATCH] Have split-include take another argument

[Tom Rini]

Hello.  The following patch makes split-include take another argument,
which is the prefix of what is being split up.  This is needed since I'm
working on a system which will allow for various params in the kernel to
be tweaked at compile-time, without offering numerous CONFIG options
(see http://marc.theaimsgroup.com/?l=linux-kernel&m=103669658505842&w=2).
I'm sending this out for two reasons.  First, does anyone see any
problems with the patch itself?  Second, Kai, would you be willing to
apply this patch now, or would should I wait until the system is ready?

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

===== Makefile 1.320 vs edited =====
--- 1.320/Makefile	Mon Nov 11 08:08:41 2002
+++ edited/Makefile	Mon Nov 11 09:30:45 2002
@@ -413,7 +413,7 @@
 
 include/config/MARKER: scripts/split-include include/linux/autoconf.h
 	@echo '  SPLIT  include/linux/autoconf.h -> include/config/*'
-	@scripts/split-include include/linux/autoconf.h include/config
+	@scripts/split-include include/linux/autoconf.h include/config CONFIG_
 	@touch $@
 
 # 	if .config is newer than include/linux/autoconf.h, someone tinkered
===== scripts/split-include.c 1.3 vs edited =====
--- 1.3/scripts/split-include.c	Sun Jun  2 18:34:13 2002
+++ edited/scripts/split-include.c	Mon Nov 11 09:29:55 2002
@@ -46,6 +46,7 @@
     const char * str_my_name;
     const char * str_file_autoconf;
     const char * str_dir_config;
+    const char * str_split_token;
 
     FILE * fp_config;
     FILE * fp_target;
@@ -61,7 +62,7 @@
     struct stat stat_buf;
 
     /* Check arg count. */
-    if (argc != 3)
+    if (argc != 4)
     {
 	fprintf(stderr, "%s: wrong number of arguments.\n", argv[0]);
 	exit(1);
@@ -70,6 +71,7 @@
     str_my_name       = argv[0];
     str_file_autoconf = argv[1];
     str_dir_config    = argv[2];
+    str_split_token   = argv[3];
 
     /* Find a buffer size. */
     if (stat(str_file_autoconf, &stat_buf) != 0)
@@ -110,11 +112,11 @@
 
 	if (line[0] != '#')
 	    continue;
-	if ((str_config = strstr(line, "CONFIG_")) == NULL)
+	if ((str_config = strstr(line, str_split_token)) == NULL)
 	    continue;
 
 	/* Make the output file name. */
-	str_config += sizeof("CONFIG_") - 1;
+	str_config += strlen(str_split_token);
 	for (itarget = 0; !isspace(str_config[itarget]); itarget++)
 	{
 	    int c = (unsigned char) str_config[itarget];

Re: [PATCH] Have split-include take another argument

[Peter Samuelson]

[Tom Rini]
> First, does anyone see any problems with the patch itself?

Well,

> -	str_config += sizeof("CONFIG_") - 1;
> +	str_config += strlen(str_split_token);

it does seem a bit inefficient to call strlen() for every single line
of every single source file.  Perhaps today's compilers know that
strlen() is invariant and has no side effects, but I vote you go ahead
and optimise it explicitly.

Peter

--- scripts/split-include.c.trini	2002-11-11 17:34:57.000000000 -0600
+++ scripts/split-include.c	2002-11-11 17:30:45.000000000 -0600
@@ -52,7 +52,7 @@
     FILE * fp_target;
     FILE * fp_find;
 
-    int buffer_size;
+    int buffer_size, split_token_len;
 
     char * line;
     char * old_line;
@@ -72,6 +72,7 @@
     str_file_autoconf = argv[1];
     str_dir_config    = argv[2];
     str_split_token   = argv[3];
+    split_token_len = strlen(str_split_token);
 
     /* Find a buffer size. */
     if (stat(str_file_autoconf, &stat_buf) != 0)
@@ -116,7 +117,7 @@
 	    continue;
 
 	/* Make the output file name. */
-	str_config += strlen(str_split_token);
+	str_config += split_token_len;
 	for (itarget = 0; !isspace(str_config[itarget]); itarget++)
 	{
 	    int c = (unsigned char) str_config[itarget];

Re: [PATCH] Have split-include take another argument

[Tom Rini]

On Mon, Nov 11, 2002 at 05:37:10PM -0600, Peter Samuelson wrote:
 
> [Tom Rini]
> > First, does anyone see any problems with the patch itself?
> 
> Well,
> 
> > -	str_config += sizeof("CONFIG_") - 1;
> > +	str_config += strlen(str_split_token);
> 
> it does seem a bit inefficient to call strlen() for every single line
> of every single source file.  Perhaps today's compilers know that
> strlen() is invariant and has no side effects, but I vote you go ahead
> and optimise it explicitly.

Sounds good, thanks.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [PATCH] Have split-include take another argument

[Kai Germaschewski]

On Mon, 11 Nov 2002, Tom Rini wrote:

> Hello.  The following patch makes split-include take another argument,
> which is the prefix of what is being split up.  This is needed since I'm
> working on a system which will allow for various params in the kernel to
> be tweaked at compile-time, without offering numerous CONFIG options
> (see http://marc.theaimsgroup.com/?l=linux-kernel&m=103669658505842&w=2).
> I'm sending this out for two reasons.  First, does anyone see any
> problems with the patch itself?  Second, Kai, would you be willing to
> apply this patch now, or would should I wait until the system is ready?

Hmmh, I think I'd rather like to wait for the rest of the patch to see 
what its actual purpose is. If at all possible, I'd like to avoid 
introducing further hacks like this into kbuild, but that's more easily 
discussed when I can see what you're trying to achieve.

--Kai

Re: [PATCH] Have split-include take another argument

[Tom Rini]

On Thu, Nov 14, 2002 at 03:01:18PM -0600, Kai Germaschewski wrote:
> On Mon, 11 Nov 2002, Tom Rini wrote:
> 
> > Hello.  The following patch makes split-include take another argument,
> > which is the prefix of what is being split up.  This is needed since I'm
> > working on a system which will allow for various params in the kernel to
> > be tweaked at compile-time, without offering numerous CONFIG options
> > (see http://marc.theaimsgroup.com/?l=linux-kernel&m=103669658505842&w=2).
> > I'm sending this out for two reasons.  First, does anyone see any
> > problems with the patch itself?  Second, Kai, would you be willing to
> > apply this patch now, or would should I wait until the system is ready?
> 
> Hmmh, I think I'd rather like to wait for the rest of the patch to see 
> what its actual purpose is. If at all possible, I'd like to avoid 
> introducing further hacks like this into kbuild, but that's more easily 
> discussed when I can see what you're trying to achieve.

Okay.  I hope to have another version of the patch out soon, and with a
few more kbuild questions once I convince myself that most of it works
(Adding in something similar to the CONFIG tweaking done by fixdep, but
with no real convinient way to see if the user changed something or
not).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/