Re: [PATCH kconfig] Add annotation symbol to configuration handling.

From: Christian Melki <christian.melki@t2data.com>
To: Boris Kolpackov <boris@codesynthesis.com>
Cc: linux-kbuild@vger.kernel.org
Subject: Re: [PATCH kconfig] Add annotation symbol to configuration handling.
Date: Tue, 11 May 2021 15:56:56 +0200	[thread overview]
Message-ID: <24c8de41-7955-bc30-8b3c-d1278878c534@t2data.com> (raw)
In-Reply-To: <boris.20210511152714@codesynthesis.com>

On 5/11/21 3:31 PM, Boris Kolpackov wrote:
> Christian Melki <christian.melki@t2data.com> writes:
> 
>> While maintaining various projects and kernels, I've often found myself
>> thinking "Why is this selected / configured?".
>>
>> Sometimes I'll find information in a disjunct documentation system or in
>> the head of somebody else. But most of the time that piece of
>> information is just lost. Configurations get moved from various
>> repositories, so that type of disconnected information also gets trashed.
>>
>> It would be nice if the configuration supported some form of simple
>> annotation to variable mechanism. Ie, part of the actual config
>> (only during read / write) and not just a whashed-away comment.
>>
>> $ grep ANNOTATE_ .config
>> ANNOTATE_CONFIG_TRANSPARENT_HUGEPAGE_MADVISE="Always was causing issues."
>> ANNOTATE_CONFIG_HID_SENSOR_HUB="Plus IIO for the Realsense camera support."
>> ANNOTATE_CONFIG_HID_SENSOR_ACCEL_3D="Used by Intel Realsense camera."
>> ANNOTATE_CONFIG_HID_SENSOR_GYRO_3D="Used by Intel Realsense camera."
> 
> Just to confirm my understanding, these annotations are expected to be
> added manually, correct? The proposed patch only makes sure they are
> preserved during the configuration read-write cycle.
> 

Correct. The example does not do away with annotations if the symbol is
deselected, but that can be changed. I'd prefer if annotations could
live a life as long as the symbol exists, that way you can follow
deselected symbols (what they were used for, if one cares to add
information).