Date
1 - 3 of 3
[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@...>
toggle quoted message
Show quoted text
-----Original Message-----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?
|
|
|
|
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.
toggle quoted message
Show quoted text
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-----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?
|
|
|