Re: [PATCH v2 5/5] pc104: Add EXPERT dependency for PC104 Kconfig option
From: William Breathitt Gray
Date: Thu Feb 22 2018 - 15:45:19 EST
On Thu, Feb 22, 2018 at 04:20:46PM +0100, Linus Walleij wrote:
>On Fri, Dec 29, 2017 at 9:14 PM, William Breathitt Gray
><vilhelm.gray@xxxxxxxxx> wrote:
>
>> PC/104 device driver Kconfig options previously had an implicit EXPERT
>> dependency by way of an explicit ISA_BUS_API dependency. Now that these
>> driver Kconfig options select ISA_BUS_API rather than depend on it, the
>> PC104 Kconfig option should have an explicit EXPERT dependency.
>>
>> The PC/104 form factor and bus architecture are common in embedded
>> and specialized systems, but uncommon in typical desktop setups. For
>> this reason, it is best to mask these devices and configurations via the
>> EXPERT Kconfig option because the majority of users will never need to
>> concern themselves with PC/104.
>>
>> Signed-off-by: William Breathitt Gray <vilhelm.gray@xxxxxxxxx>
>
>Patch applied to the GPIO tree for v4.17.
>
>I don't know what kind of definition of "expert" really applies here.
>
>Who in their right mind think that novices are using the kernel
>configuration interface. Isn't anyone doing kernel compiles
>entitled to be called an expert...
>
>Anyways I guess this has already been discussed.
>
>Yours,
>Linus Walleij
I'm inclined to agree with you on this point. I believe there is benefit
in masking uncommon hardware configurations such as PC/104 in order to
reduce clutter in the menus, but you are right that "expert" sounds
somewhat of a misnomer for this use case. I considered adding yet
another Kconfig option to mask these options, but since Kconfig code
isn't my forte, I ultimately decided to keep it simple and depend simply
on EXPERT.
The PC104 Kconfig option has been implicitly masked by EXPERT up to this
point, so I thought it best to keep it masked as it has been thus far.
However, since all this masking is essentially just an aesthetic matter,
I'm somewhat indifferent and open to removing the EXPERT dependency
as well; I'll let someone else make that call rather I.
William Breathitt Gray