[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFkk2KRF+OLGajqgevK8Cj6J3eFqFgTaywcmQGu-BZ8=faUPhQ@mail.gmail.com>
Date: Wed, 13 Dec 2017 19:43:46 +0100
From: Ulf Magnusson <ulfalizer@...il.com>
To: Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc: "Yann E. MORIN" <yann.morin.1998@...e.fr>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Michal Marek <mmarek@...e.cz>,
Arnaud Lacombe <lacombar@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kconfig: Remove menu_end_entry()
On Wed, Dec 13, 2017 at 5:32 PM, Ulf Magnusson <ulfalizer@...il.com> wrote:
> On Sat, Dec 9, 2017 at 5:27 PM, Masahiro Yamada
> <yamada.masahiro@...ionext.com> wrote:
>> 2017-10-05 11:36 GMT+09:00 Ulf Magnusson <ulfalizer@...il.com>:
>>> 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 <ulfalizer@...il.com>
>>> ---
>>
>> 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
Powered by blists - more mailing lists