Re: [RFC 0/6] Regressions for "imply" behavior change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16.04.2020 20:21, Jason Gunthorpe wrote:
> On Thu, Apr 16, 2020 at 11:12:56AM -0400, Nicolas Pitre wrote:
>> On Thu, 16 Apr 2020, Arnd Bergmann wrote:
>>
>>> On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula
>>> <jani.nikula@xxxxxxxxxxxxxxx> wrote:
>>>> On Thu, 16 Apr 2020, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>>>> On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed <saeedm@xxxxxxxxxxxx> wrote:
>>>>>> BTW how about adding a new Kconfig option to hide the details of
>>>>>> ( BAR || !BAR) ? as Jason already explained and suggested, this will
>>>>>> make it easier for the users and developers to understand the actual
>>>>>> meaning behind this tristate weird condition.
>>>>>>
>>>>>> e.g have a new keyword:
>>>>>>       reach VXLAN
>>>>>> which will be equivalent to:
>>>>>>       depends on VXLAN && !VXLAN
>>>>> I'd love to see that, but I'm not sure what keyword is best. For your
>>>>> suggestion of "reach", that would probably do the job, but I'm not
>>>>> sure if this ends up being more or less confusing than what we have
>>>>> today.
>>>> Ah, perfect bikeshedding topic!
>>>>
>>>> Perhaps "uses"? If the dependency is enabled it gets used as a
>>>> dependency.
>>> That seems to be the best naming suggestion so far
>> What I don't like about "uses" is that it doesn't convey the conditional
>> dependency. It could be mistaken as being synonymous to "select".
>>
>> What about "depends_if" ? The rationale is that this is actually a
>> dependency, but only if the related symbol is set (i.e. not n or empty).
> I think that stretches the common understanding of 'depends' a bit too
> far.. A depends where the target can be N is just too strange.
>
> Somthing incorporating 'optional' seems like a better choice
> 'optionally uses' seems particularly clear and doesn't overload
> existing works like depends or select


I think the whole misunderstanding with imply is that ppl try to use it 
as weak 'depend on' but it is weak 'select' - ie it enforces value of 
implied symbol in contrast to 'depends' which enforces value of current 
symbol.

So if we want to add new symbol 'weak depend' it would be good to stress 
out that difference.

Moreover name imply is already cryptic, adding another keyword which for 
sure will be cryptic (as there are no natural candidates) will 
complicate things more.

Maybe adding some decorator would be better, like optionally or weak, 
for example:

optionally depends on X

optionally select Y

Even more readable:

depends on X if on

depends on Y if enabled


Regards

Andrzej


>
> Jason
>



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux