2017-10-05 11:36 GMT+09:00 Ulf Magnusson <[email protected]>:
> 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.
>
> 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/)
--
Best Regards
Masahiro Yamada
On Sat, Dec 9, 2017 at 5:27 PM, Masahiro Yamada
<[email protected]> wrote:
> 2017-10-05 11:36 GMT+09:00 Ulf Magnusson <[email protected]>:
>> 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.
>>
>> 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/)
>
>
> --
> 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
On Wed, Dec 13, 2017 at 5:32 PM, Ulf Magnusson <[email protected]> wrote:
> On Sat, Dec 9, 2017 at 5:27 PM, Masahiro Yamada
> <[email protected]> wrote:
>> 2017-10-05 11:36 GMT+09:00 Ulf Magnusson <[email protected]>:
>>> 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.
>>>
>>> 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/)
>>
>>
>> --
>> 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
Thanks for stepping in and merging those earlier Kconfig patches by
the way! Only
noticed just now.
Cheers,
Ulf