kconfig: Remove menu_end_entry()
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
@@ -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
@@ -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 = ¤t_entry->list;return current_menu = current_entry; }
scripts/kconfig/zconf.tab.c_shipped +10 -20
@@ -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
@@ -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
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-rc2Last 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.
Signed-off-by Ulf Magnusson <[email protected]>---
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
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-rc2Last 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.
Signed-off-by Ulf Magnusson <[email protected]>---
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
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-rc2Last 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.
Signed-off-by Ulf Magnusson <[email protected]>---
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