[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <542F3892.7090001@infradead.org>
Date: Fri, 03 Oct 2014 17:00:18 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Josh Triplett <josh@...htriplett.org>
CC: "Yann E. MORIN" <yann.morin.1998@...e.fr>,
Andrew Morton <akpm@...ux-foundation.org>,
Eric Paris <eparis@...hat.com>, Michal Hocko <mhocko@...e.cz>,
Matt Turner <mattst88@...il.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
蔡正龙 <zhenglong.cai@...c.com.cn>,
Tejun Heo <tj@...nel.org>, Fabian Frederick <fabf@...net.be>,
"Luis R. Rodriguez" <mcgrof@...e.com>,
Peter Foley <pefoley2@...oley.com>,
Konstantin Khlebnikov <koct9i@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"H. Peter Anvin" <hpa@...or.com>, Oleg Nesterov <oleg@...hat.com>,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break
up the EXPERT menu
On 10/03/14 16:47, Josh Triplett wrote:
> On Fri, Oct 03, 2014 at 04:36:36PM -0700, Randy Dunlap wrote:
>> On 10/03/14 16:31, Josh Triplett wrote:
>>> commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow
>>> architectures to skip futex_atomic_cmpxchg_inatomic() test") added the
>>> HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in
>>> the middle of the options for the EXPERT menu. However,
>>> HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops
>>> placing items in the EXPERT menu, and displays the remaining several
>>> EXPERT items (starting with EPOLL) directly in the General Setup menu.
>>>
>>> Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make
>>> HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the
>>> subsequent items display as part of the EXPERT menu again; the EMBEDDED
>>> menu now appears as the next top-level item in the General Setup menu,
>>> which makes General Setup much shorter and more usable.
>>>
>>> Signed-off-by: Josh Triplett <josh@...htriplett.org>
>>> ---
>>>
>>> Posting for review. I can upstream this through the tiny tree.
>>>
>>> Personally, I'd consider this a bit of a bug in Kconfig; ideally,
>>> Kconfig should only consider symbols with prompt strings when
>>> considering what to display in a menu. However, in the interim, this
>>> one-line patch drastically improves the usability of the "General Setup"
>>> config menu.
>>
>> Good catch. Thanks.
>>
>> I would prefer to see both of your patches merged quickly into 3.17 no matter
>> how they get there.
>>
>> both patches:
>> Acked-by: Randy Dunlap <rdunlap@...radead.org>
>
> Both of the fixes are entirely about Kconfig usability, don't affect the
> built kernel, and have existed for quite a few kernel releases, so I
> hadn't planned to get them into 3.17 at the last minute. I'd just
> planned to submit them during the 3.18 merge window when that opens.
>
> Do you really think they should be pushed into 3.17 at this point?
Both of them are bugs IMO, even though they are usability/presentation bugs.
and they make the menu system confusing.
> If you'd like, I could get them into 3.18 and mark them for stable,
> instead.
Do that at a minimum, please.
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists