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