2019-11-25 12:57:19

by Marek Szyprowski

[permalink] [raw]
Subject: [PATCH] arm: exynos_config: Restore debugfs support

Commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency")
removed the dependency between DEBUG_FS and TRACING, so DEBUG_FS is no
longer enabled in default builds. Enable it again manually, as it provides
a lots of useful data for automated testing tools.

Signed-off-by: Marek Szyprowski <[email protected]>
---
arch/arm/configs/exynos_defconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index e7e4bb5ad8d5..fde84f123fbb 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -350,6 +350,7 @@ CONFIG_PRINTK_TIME=y
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DEBUG_INFO=y
CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_SOFTLOCKUP_DETECTOR=y
# CONFIG_DETECT_HUNG_TASK is not set
--
2.17.1


Subject: Re: [PATCH] arm: exynos_config: Restore debugfs support


On 11/25/19 3:39 PM, Steven Rostedt wrote:
> On Mon, 25 Nov 2019 15:30:39 +0100
> Bartlomiej Zolnierkiewicz <[email protected]> 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).

> way belongs to the patch that removed DEBUG_FS from TRACING.
>
> -- Steve
>
>
>> - let platform maintainers disable DEBUG_FS manually in corresponding
>> defconfigs later if desirable

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Subject: Re: [PATCH] arm: exynos_config: Restore debugfs support


Hi,

On 11/25/19 1:55 PM, Marek Szyprowski wrote:
> Commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency")
> removed the dependency between DEBUG_FS and TRACING, so DEBUG_FS is no
> longer enabled in default builds. Enable it again manually, as it provides
> a lots of useful data for automated testing tools.
>
> Signed-off-by: Marek Szyprowski <[email protected]>
> ---
> arch/arm/configs/exynos_defconfig | 1 +
> 1 file changed, 1 insertion(+)

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

- let platform maintainers disable DEBUG_FS manually in corresponding
defconfigs later if desirable

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index e7e4bb5ad8d5..fde84f123fbb 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -350,6 +350,7 @@ CONFIG_PRINTK_TIME=y
> CONFIG_DYNAMIC_DEBUG=y
> CONFIG_DEBUG_INFO=y
> CONFIG_MAGIC_SYSRQ=y
> +CONFIG_DEBUG_FS=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_SOFTLOCKUP_DETECTOR=y
> # CONFIG_DETECT_HUNG_TASK is not set

2019-11-25 18:40:36

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH] arm: exynos_config: Restore debugfs support

On Mon, 25 Nov 2019 15:30:39 +0100
Bartlomiej Zolnierkiewicz <[email protected]> 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
way belongs to the patch that removed DEBUG_FS from TRACING.

-- Steve


> - let platform maintainers disable DEBUG_FS manually in corresponding
> defconfigs later if desirable

2019-11-26 01:24:17

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH] arm: exynos_config: Restore debugfs support

On Mon, 25 Nov 2019 at 23:31, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
>
>
> On 11/25/19 3:39 PM, Steven Rostedt wrote:
> > On Mon, 25 Nov 2019 15:30:39 +0100
> > Bartlomiej Zolnierkiewicz <[email protected]> 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