Skip to contentSkip to conversation

kconfig: Remove menu_end_entry()

PATCH Superseded Ulf Magnusson 2 participants 4 messages Oct 5, 2017 – Dec 13, 2017

Subsystems (2)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 kconfig: Remove menu_end_entry()

menu_end_entry() is empty and completely unused as far as I can tell:

	$ git log -G menu_end_entry --oneline
	a02f057 [PATCH] kconfig: improve error handling in the parser
	1da177e Linux-2.6.12-rc2

Last one is the initial Git commit, where menu_end_entry() is empty as well. I couldn't find anything that redefined it on Google either.

It might be a debugging helper for setting a breakpoint after each config, menuconfig, and comment is parsed. IMO it hurts more than it helps in that case by making the parsing code look more complicated at a glance than it really is, and I suspect it doesn't get used much.

Tested by running the Kconfiglib test suite, which indirectly verifies that the .config files generated by the C implementation for each defconfig file in the kernel stays the same.

---
 scripts/kconfig/lkc.h               |  1 -
 scripts/kconfig/menu.c              |  5 -----
 scripts/kconfig/zconf.tab.c_shipped | 30 ++++++++++--------------------
 scripts/kconfig/zconf.y             |  6 +-----
 4 files changed, 11 insertions(+), 31 deletions(-)
scripts/kconfig/lkc.h +0 -1
index cdcbe43..16cb62b 100644
@@ -100,7 +100,6 @@ void menu_warn(struct menu *menu, const char *fmt, ...);
 struct menu *menu_add_menu(void);
 void menu_end_menu(void);
 void menu_add_entry(struct symbol *sym);
-void menu_end_entry(void);
 void menu_add_dep(struct expr *dep);
 void menu_add_visibility(struct expr *dep);
 struct property *menu_add_prompt(enum prop_type type, char *prompt, struct expr *dep);
scripts/kconfig/menu.c +0 -5
index e935793..503f3ae 100644
@@ -62,13 +62,8 @@ void menu_add_entry(struct symbol *sym)
 		menu_add_symbol(P_SYMBOL, sym, NULL);
 }
 
-void menu_end_entry(void)
-{
-}
-
 struct menu *menu_add_menu(void)
 {
-	menu_end_entry();
 	last_entry_ptr = &current_entry->list;
 	return current_menu = current_entry;
 }
scripts/kconfig/zconf.tab.c_shipped +10 -20
index a22b285..7938548 100644
@@ -516,16 +516,16 @@ static const yytype_uint16 yyrline[] =
        0,   109,   109,   109,   111,   111,   113,   115,   116,   117,
      118,   119,   120,   124,   128,   128,   128,   128,   128,   128,
      128,   128,   128,   132,   133,   134,   135,   136,   137,   141,
-     142,   148,   156,   162,   170,   180,   182,   183,   184,   185,
-     186,   187,   190,   198,   204,   214,   220,   226,   232,   235,
-     237,   248,   249,   254,   263,   268,   276,   279,   281,   282,
-     283,   284,   285,   288,   294,   305,   311,   321,   323,   328,
-     336,   344,   347,   349,   350,   351,   356,   363,   370,   375,
-     383,   386,   388,   389,   390,   393,   401,   408,   415,   421,
-     428,   430,   431,   432,   435,   443,   445,   446,   449,   456,
-     458,   463,   464,   467,   468,   469,   473,   474,   477,   478,
-     481,   482,   483,   484,   485,   486,   487,   488,   489,   490,
-     491,   494,   495,   498,   499
+     142,   148,   156,   161,   169,   178,   180,   181,   182,   183,
+     184,   185,   188,   196,   202,   212,   218,   224,   230,   233,
+     235,   246,   247,   252,   261,   266,   274,   277,   279,   280,
+     281,   282,   283,   286,   292,   303,   309,   319,   321,   326,
+     334,   342,   345,   347,   348,   349,   354,   361,   368,   373,
+     381,   384,   386,   387,   388,   391,   399,   406,   411,   417,
+     424,   426,   427,   428,   431,   439,   441,   442,   445,   452,
+     454,   459,   460,   463,   464,   465,   469,   470,   473,   474,
+     477,   478,   479,   480,   481,   482,   483,   484,   485,   486,
+     487,   490,   491,   494,   495
 };
 #endif
 
@@ -1552,7 +1552,6 @@ yyreduce:
   case 32:
 
     {
-	menu_end_entry();
 	printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno());
 }
 
@@ -1576,7 +1575,6 @@ yyreduce:
 		current_entry->prompt->type = P_MENU;
 	else
 		zconfprint("warning: menuconfig statement without prompt");
-	menu_end_entry();
 	printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno());
 }
 
@@ -1821,14 +1819,6 @@ yyreduce:
 
     break;
 
-  case 87:
-
-    {
-	menu_end_entry();
-}
-
-    break;
-
   case 88:
 
     {
scripts/kconfig/zconf.y +1 -5
index c8f396c..3845aa9 100644
@@ -155,7 +155,6 @@ config_entry_start: T_CONFIG T_WORD T_EOL
 
 config_stmt: config_entry_start config_option_list
 {
-	menu_end_entry();
 	printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno());
 };
 
@@ -173,7 +172,6 @@ menuconfig_stmt: menuconfig_entry_start config_option_list
 		current_entry->prompt->type = P_MENU;
 	else
 		zconfprint("warning: menuconfig statement without prompt");
-	menu_end_entry();
 	printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno());
 };
 
@@ -406,9 +404,7 @@ comment: T_COMMENT prompt T_EOL
 };
 
 comment_stmt: comment depends_list
-{
-	menu_end_entry();
-};
+;
 
 /* help option */
 
Signature · 1 line
2.7.4
#1 lore raw

2017-10-05 11:36 GMT+09:00 Ulf Magnusson <[email protected]>:

Quoted 14 lines

menu_end_entry() is empty and completely unused as far as I can tell:

        $ git log -G menu_end_entry --oneline
        a02f057 [PATCH] kconfig: improve error handling in the parser
        1da177e Linux-2.6.12-rc2

Last one is the initial Git commit, where menu_end_entry() is empty as well. I couldn't find anything that redefined it on Google either.

It might be a debugging helper for setting a breakpoint after each config, menuconfig, and comment is parsed. IMO it hurts more than it helps in that case by making the parsing code look more complicated at a glance than it really is, and I suspect it doesn't get used much.

Quoted 6 lines

Tested by running the Kconfiglib test suite, which indirectly verifies that the .config files generated by the C implementation for each defconfig file in the kernel stays the same.

---

Removing menu_end_entry() should be OK,
but it is tedious to sync *.y and *_shipped.

I'd like to apply v2 (https://patchwork.kernel.org/patch/9992029/)
on top of my patch (https://patchwork.kernel.org/patch/10103743/)

Signature · 2 lines
Best Regards
Masahiro Yamada
#2 lore raw
Quoted 25 lines · Masahiro Yamada

2017-10-05 11:36 GMT+09:00 Ulf Magnusson <[email protected]>:

Quoted 14 lines

menu_end_entry() is empty and completely unused as far as I can tell:

        $ git log -G menu_end_entry --oneline
        a02f057 [PATCH] kconfig: improve error handling in the parser
        1da177e Linux-2.6.12-rc2

Last one is the initial Git commit, where menu_end_entry() is empty as well. I couldn't find anything that redefined it on Google either.

It might be a debugging helper for setting a breakpoint after each config, menuconfig, and comment is parsed. IMO it hurts more than it helps in that case by making the parsing code look more complicated at a glance than it really is, and I suspect it doesn't get used much.

Quoted 6 lines

Tested by running the Kconfiglib test suite, which indirectly verifies that the .config files generated by the C implementation for each defconfig file in the kernel stays the same.

---

Removing menu_end_entry() should be OK,
but it is tedious to sync *.y and *_shipped.

Quoted 7 lines

I'd like to apply v2 (https://patchwork.kernel.org/patch/9992029/)
on top of my patch (https://patchwork.kernel.org/patch/10103743/)

--
Best Regards
Masahiro Yamada

Fine by me, if people have no objections to adding Flex and Bison as build-time requirements. Looks like you already went over it in
https://lkml.org/lkml/2017/8/19/49.

Cheers,
Ulf

#3 lore raw
Quoted 35 lines · Ulf Magnusson
Quoted 25 lines · Masahiro Yamada

2017-10-05 11:36 GMT+09:00 Ulf Magnusson <[email protected]>:

Quoted 14 lines

menu_end_entry() is empty and completely unused as far as I can tell:

        $ git log -G menu_end_entry --oneline
        a02f057 [PATCH] kconfig: improve error handling in the parser
        1da177e Linux-2.6.12-rc2

Last one is the initial Git commit, where menu_end_entry() is empty as well. I couldn't find anything that redefined it on Google either.

It might be a debugging helper for setting a breakpoint after each config, menuconfig, and comment is parsed. IMO it hurts more than it helps in that case by making the parsing code look more complicated at a glance than it really is, and I suspect it doesn't get used much.

Quoted 6 lines

Tested by running the Kconfiglib test suite, which indirectly verifies that the .config files generated by the C implementation for each defconfig file in the kernel stays the same.

---

Removing menu_end_entry() should be OK,
but it is tedious to sync *.y and *_shipped.

Quoted 7 lines

I'd like to apply v2 (https://patchwork.kernel.org/patch/9992029/)
on top of my patch (https://patchwork.kernel.org/patch/10103743/)

--
Best Regards
Masahiro Yamada

Quoted 6 lines

Fine by me, if people have no objections to adding Flex and Bison as build-time requirements. Looks like you already went over it in
https://lkml.org/lkml/2017/8/19/49.

Cheers,
Ulf

Thanks for stepping in and merging those earlier Kconfig patches by the way! Only
noticed just now.

Cheers,
Ulf