-----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