Topics

[RFC] Simplifying disable of Kconfig Debugging options

Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
 

Hello, please check this proposal and provide feedback if possible.
 
Background:
 
Currently several debugging options exists on Kconfig menu but they are not on a single debug submenu, e.g.:
- /Networking/Bluetooth support/Bluetooth debug support/*
- /Networking/Generic networking support/Network Ethernet driver debug
- /x86 architecture/Allows the usage of GDB with the ARC processor
- /Debugging Options/*
This means changing many debug settings at once becomes difficult and might led to developer overlooking some options.
 
Disabling all the debug features at once could be a frequent task when the footprint size is constantly kept in mind during development. If further debugging is required later, the process to re-enable several features will follow.
 
Consequently we want to make toggle of many debug settings at once as straight forward as possible.
 
Proposal to simplify the switching of multiple debug options at once:
 
1st approach: Original proposal suggested moving all options to a single menu, this will minimize the navigation between submenus.
 
This alternative was ruled out as the debug options taken out of original context won't let the developer know the details of the feature.

Duplicating options instead of removing them from the original context would complicate the menu and learning to use or to modify it.
 
2nd approach: Group features on debug levels and differentiate the debug features (both build and run time) from printing/logging features. First this alternative separates printing functionality from actual debugging features, printing would include current printk and printf related options plus possible more complex logging features to be developed in the future.
 
Regarding debugging features these could be classified in multiple levels instead of a single global switch, by reducing the debug level a developer could decrease the foot print in a simple manner while keeping logging/printing.

Several levels could be defined or additional categories, as an example the following menu specifies two debug levels (1st and 4th
options) and a single additional category (printing/logging):

[*] Build kernel with debugging
[*] Generate stack usage information
[ ] Enable printing
[ ] Enable run time debugging features
 
By disabling "Enable run time debugging features" the most complex features get disabled. Although not visible from '/Debugging Options' some network debug options would be disabled, some build time options and some low footprint impact options would remain available, logging category would also be available. The next level (1st option) disables all debugging options but those in drivers, as drivers usually have very diverse implementation, logging category would still be available.
 
Additional categories could be network and drivers but it cannot be guaranteed/enforced that new driver developers will follow such pattern on Kconfig files.

Additional debug levels could produce a finer grain classification regarding foot print and other drawbacks such as performance degradation.

It still remains an open issue turning on several options, as SELECT on Kconfig is problematic and maybe original intent was not to turn it all on but turn the previous selection on. Developer would have to back up his last debugging '.config' file to re-enable.

3rd approach: as an extreme alternative, in case modifying Kconfig menus is not viable, would be externally dealing with '.config' files.
using developer triggered scripts like merge_config.sh already part of make build process.

Developers would be able to specify debug presets using a new option in the per-application Makefile or passing a make command argument: (make ... DEBUG_PRESET='network2.conf kernel.conf').

Presets already on the repository could be used and developers could define their own.

Currently make script merges 3 configuration files: board, nanokernel XOR microkernel and project specific conf. Additional argument would be added to the merge command, these arguments being the developer selected debug presets.

An example preset with some variables for illustrative purpose:

$ cat network2.conf
#Level 2 network debugging preset
#prerequisite settings
NETWORKING_WITH_LOGGING=y
STDOUT_CONSOLE=y
NET_BUF_DEBUG=y
#debug settings
NETWORKING_STATISTICS=y
NETWORKING_DEBUG_UART=y
ETHERNET_DEBUG=y
TINYDTLS_DEBUG=y
NET_BUF_DEBUG=y
BLUETOOTH_DEBUG=y
BLUETOOTH_DEBUG_COLOR=y
BLUETOOTH_DEBUG_HCI_CORE=n
BLUETOOTH_DEBUG_CONN=y
BLUETOOTH_DEBUG_KEYS=n
BLUETOOTH_DEBUG_L2CAP=y
BLUETOOTH_SMP_SELFTEST=y
BLUETOOTH_DEBUG_ATT=n
BLUETOOTH_DEBUG_GATT=n

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Saucedo Tejada, Genaro [mailto:genaro.saucedo.tejada(a)intel.com]
Sent: Friday, February 12, 2016 8:51 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC] Simplifying disable of Kconfig Debugging options

Hello, please check this proposal and provide feedback if possible.

Background:

Currently several debugging options exists on Kconfig menu but they are not
on a single debug submenu, e.g.:
- /Networking/Bluetooth support/Bluetooth debug support/*
- /Networking/Generic networking support/Network Ethernet driver debug
- /x86 architecture/Allows the usage of GDB with the ARC processor
- /Debugging Options/*
This means changing many debug settings at once becomes difficult and
might led to developer overlooking some options.

Disabling all the debug features at once could be a frequent task when the
footprint size is constantly kept in mind during development. If further
debugging is required later, the process to re-enable several features will
follow.

Consequently we want to make toggle of many debug settings at once as
straight forward as possible.

Proposal to simplify the switching of multiple debug options at once:
Out of these proposals, it's not really clear to me how any of them would be more simple than just putting the debug options you are interested in to a PRJ file, and using that to {un}set the value at compile time.

Could you clarify why your proposals would work better?



1st approach: Original proposal suggested moving all options to a single
menu, this will minimize the navigation between submenus.

This alternative was ruled out as the debug options taken out of original
context won't let the developer know the details of the feature.

Duplicating options instead of removing them from the original context
would complicate the menu and learning to use or to modify it.

2nd approach: Group features on debug levels and differentiate the debug
features (both build and run time) from printing/logging features. First this
alternative separates printing functionality from actual debugging features,
printing would include current printk and printf related options plus possible
more complex logging features to be developed in the future.

Regarding debugging features these could be classified in multiple levels
instead of a single global switch, by reducing the debug level a developer
could decrease the foot print in a simple manner while keeping
logging/printing.

Several levels could be defined or additional categories, as an example the
following menu specifies two debug levels (1st and 4th
options) and a single additional category (printing/logging):

[*] Build kernel with debugging
[*] Generate stack usage information
[ ] Enable printing
[ ] Enable run time debugging features

By disabling "Enable run time debugging features" the most complex
features get disabled. Although not visible from '/Debugging Options' some
network debug options would be disabled, some build time options and
some low footprint impact options would remain available, logging category
would also be available. The next level (1st option) disables all debugging
options but those in drivers, as drivers usually have very diverse
implementation, logging category would still be available.

Additional categories could be network and drivers but it cannot be
guaranteed/enforced that new driver developers will follow such pattern on
Kconfig files.

Additional debug levels could produce a finer grain classification regarding
foot print and other drawbacks such as performance degradation.

It still remains an open issue turning on several options, as SELECT on Kconfig
is problematic and maybe original intent was not to turn it all on but turn the
previous selection on. Developer would have to back up his last debugging
'.config' file to re-enable.

3rd approach: as an extreme alternative, in case modifying Kconfig menus is
not viable, would be externally dealing with '.config' files.
using developer triggered scripts like merge_config.sh already part of make
build process.

Developers would be able to specify debug presets using a new option in the
per-application Makefile or passing a make command argument: (make ...
DEBUG_PRESET='network2.conf kernel.conf').

Presets already on the repository could be used and developers could define
their own.

Currently make script merges 3 configuration files: board, nanokernel XOR
microkernel and project specific conf. Additional argument would be added
to the merge command, these arguments being the developer selected
debug presets.

An example preset with some variables for illustrative purpose:

$ cat network2.conf
#Level 2 network debugging preset
#prerequisite settings
NETWORKING_WITH_LOGGING=y
STDOUT_CONSOLE=y
NET_BUF_DEBUG=y
#debug settings
NETWORKING_STATISTICS=y
NETWORKING_DEBUG_UART=y
ETHERNET_DEBUG=y
TINYDTLS_DEBUG=y
NET_BUF_DEBUG=y
BLUETOOTH_DEBUG=y
BLUETOOTH_DEBUG_COLOR=y
BLUETOOTH_DEBUG_HCI_CORE=n
BLUETOOTH_DEBUG_CONN=y
BLUETOOTH_DEBUG_KEYS=n
BLUETOOTH_DEBUG_L2CAP=y
BLUETOOTH_SMP_SELFTEST=y
BLUETOOTH_DEBUG_ATT=n
BLUETOOTH_DEBUG_GATT=n

Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
 

Your proposal seems the simplest to me, the only advantage I see on the more complex one is flexibility, presets could provide settings for multiple scenarios rather than on|off.

I would add your observation as a 4th alternative and submit for consideration whether all the complexity previously proposed is worth it.

-----Original Message-----
From: Kalowsky, Daniel
Sent: Wednesday, February 17, 2016 01:07
To: Saucedo Tejada, Genaro <genaro.saucedo.tejada(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Simplifying disable of Kconfig Debugging options

-----Original Message-----
From: Saucedo Tejada, Genaro [mailto:genaro.saucedo.tejada(a)intel.com]
Sent: Friday, February 12, 2016 8:51 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC] Simplifying disable of Kconfig Debugging
options

Hello, please check this proposal and provide feedback if possible.

Background:

Currently several debugging options exists on Kconfig menu but they
are not on a single debug submenu, e.g.:
- /Networking/Bluetooth support/Bluetooth debug support/*
- /Networking/Generic networking support/Network Ethernet driver debug
- /x86 architecture/Allows the usage of GDB with the ARC processor
- /Debugging Options/*
This means changing many debug settings at once becomes difficult and
might led to developer overlooking some options.

Disabling all the debug features at once could be a frequent task when
the footprint size is constantly kept in mind during development. If
further debugging is required later, the process to re-enable several
features will follow.

Consequently we want to make toggle of many debug settings at once as
straight forward as possible.

Proposal to simplify the switching of multiple debug options at once:
Out of these proposals, it's not really clear to me how any of them would be more simple than just putting the debug options you are interested in to a PRJ file, and using that to {un}set the value at compile time.

Could you clarify why your proposals would work better?



1st approach: Original proposal suggested moving all options to a
single menu, this will minimize the navigation between submenus.

This alternative was ruled out as the debug options taken out of
original context won't let the developer know the details of the feature.

Duplicating options instead of removing them from the original context
would complicate the menu and learning to use or to modify it.

2nd approach: Group features on debug levels and differentiate the
debug features (both build and run time) from printing/logging
features. First this alternative separates printing functionality from
actual debugging features, printing would include current printk and
printf related options plus possible more complex logging features to be developed in the future.

Regarding debugging features these could be classified in multiple
levels instead of a single global switch, by reducing the debug level
a developer could decrease the foot print in a simple manner while
keeping logging/printing.

Several levels could be defined or additional categories, as an
example the following menu specifies two debug levels (1st and 4th
options) and a single additional category (printing/logging):

[*] Build kernel with debugging
[*] Generate stack usage information
[ ] Enable printing
[ ] Enable run time debugging features

By disabling "Enable run time debugging features" the most complex
features get disabled. Although not visible from '/Debugging Options'
some network debug options would be disabled, some build time options
and some low footprint impact options would remain available, logging
category would also be available. The next level (1st option) disables
all debugging options but those in drivers, as drivers usually have
very diverse implementation, logging category would still be available.

Additional categories could be network and drivers but it cannot be
guaranteed/enforced that new driver developers will follow such
pattern on Kconfig files.

Additional debug levels could produce a finer grain classification
regarding foot print and other drawbacks such as performance degradation.

It still remains an open issue turning on several options, as SELECT
on Kconfig is problematic and maybe original intent was not to turn it
all on but turn the previous selection on. Developer would have to
back up his last debugging '.config' file to re-enable.

3rd approach: as an extreme alternative, in case modifying Kconfig
menus is not viable, would be externally dealing with '.config' files.
using developer triggered scripts like merge_config.sh already part of
make build process.

Developers would be able to specify debug presets using a new option
in the per-application Makefile or passing a make command argument: (make ...
DEBUG_PRESET='network2.conf kernel.conf').

Presets already on the repository could be used and developers could
define their own.

Currently make script merges 3 configuration files: board, nanokernel
XOR microkernel and project specific conf. Additional argument would
be added to the merge command, these arguments being the developer
selected debug presets.

An example preset with some variables for illustrative purpose:

$ cat network2.conf
#Level 2 network debugging preset
#prerequisite settings
NETWORKING_WITH_LOGGING=y
STDOUT_CONSOLE=y
NET_BUF_DEBUG=y
#debug settings
NETWORKING_STATISTICS=y
NETWORKING_DEBUG_UART=y
ETHERNET_DEBUG=y
TINYDTLS_DEBUG=y
NET_BUF_DEBUG=y
BLUETOOTH_DEBUG=y
BLUETOOTH_DEBUG_COLOR=y
BLUETOOTH_DEBUG_HCI_CORE=n
BLUETOOTH_DEBUG_CONN=y
BLUETOOTH_DEBUG_KEYS=n
BLUETOOTH_DEBUG_L2CAP=y
BLUETOOTH_SMP_SELFTEST=y
BLUETOOTH_DEBUG_ATT=n
BLUETOOTH_DEBUG_GATT=n