On Mon, 25 Nov 2019 at 23:31, Bartlomiej Zolnierkiewicz
<b.zolnierkie@xxxxxxxxxxx> wrote:
>
>
> On 11/25/19 3:39 PM, Steven Rostedt wrote:
> > On Mon, 25 Nov 2019 15:30:39 +0100
> > Bartlomiej Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx> wrote:
> >
> >> It seems that commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS
> >> dependency") disabled DEBUG_FS also in some other ARM defconfigs.
> >>
> >> For some of them it may be a correct change but a preferred way to
> >> introduce such changes would be to:
> >>
> >> - add explicit CONFIG_DEBUG_FS=y instances to all affected defconfigs
> >> while removing DEBUG_FS selection from TRACING config item
> >>
> >
> > I strongly disagree. It was wrong to assume DEBUG_FS is attached to
> > TRACING. If someone wanted DEBUG_FS in their def config, they should
> > have added it specifically. The addition of DEBUG_FS to defconfigs no
>
> There is a theory and a practice.
>
> In theory you are are correct. ;-)
>
> In practice people don't manually edit configuration files nowadays.
>
> They do 'make menuconfig' and enable what they need and disable what
> they do not need. Then they do 'make savedefconfig' and copy resulting
> "stripped" defconfig file as their new platform defconfig. As a result
> defconfigs rely on many default settings (also they explicitly disable
> only items that are enabled by default but you don't want them).
I agree with Bartłomiej. Your interpretation Steven essentially
prohibits any use of savedefconfig to trim automatically the config
from unneeded options. Therefore many defconfigs which do not have
DEBUG_FS or other options directly, but they want it.
Some time ago I had patches removing specific non-existing options
from defconfigs. For each option I provided a rationale that it is
gone/etc so let's remove it from defconfig. Most of maintainers picked
them up but few (2-3?) instead run savedefconfig to clean up
everything automatically.
Best regards,
Krzysztof
