New Kconfig convention: Extra indentation in comments will render as HTML preformatted text

11 files changed, 146 insertions, 121 deletions

diff --git a/apps/netutils/resolv/Kconfig b/apps/netutils/resolv/Kconfig
index 07a0fd4bc..b9e9b68b0 100644
--- a/apps/netutils/resolv/Kconfig
+++ b/apps/netutils/resolv/Kconfig
@@ -23,4 +23,4 @@ config NET_RESOLV_MAXRESPONSE
 	---help---
 		This setting determines the maximum size of response message that can be
 		received by the DNS resolver.  The default is 96 but may need to be larger on
- 		enterprise networks (perhaps 176).
+		enterprise networks (perhaps 176).
diff --git a/apps/netutils/thttpd/Kconfig b/apps/netutils/thttpd/Kconfig
index d181ec886..403ce8092 100644
--- a/apps/netutils/thttpd/Kconfig
+++ b/apps/netutils/thttpd/Kconfig
@@ -204,18 +204,18 @@ choice
 		an actual filename.
 
 		1) Map ~username to <prefix>/username. This is the recommended
-		   choice. Each user gets a subdirectory in the main web tree, and
-		   the tilde construct points there.
+		choice. Each user gets a subdirectory in the main web tree, and
+		the tilde construct points there.
 
-		   The prefix could be something like "users", or it could be empty.
+		The prefix could be something like "users", or it could be empty.
 
 		2) Map ~username to <user's homedir>/<postfix>. The postfix would be
-		   the name of a subdirectory off of the user's actual home dir,
-		   something like "public_html".
+		the name of a subdirectory off of the user's actual home dir,
+		something like "public_html".
 
 		3) Niether.  You can also leave both options undefined, and thttpd
-		   will not do anything special about tildes. Enabling both options
-		   is an error.
+		will not do anything special about tildes. Enabling both options
+		is an error.
 
 		Typical values, if they're defined, are "users" for THTTPD_TILDE_MAP1
 		and "public_html" for THTTPD_TILDE_MAP2. 
@@ -228,10 +228,10 @@ config THTTPD_USE_TILDE_MAP1
 		an actual filename.  Choose this option for the first mapping:
 
 		1) Map ~username to <prefix>/username. This is the recommended
-		   choice. Each user gets a subdirectory in the main web tree, and
-		   the tilde construct points there.
+		choice. Each user gets a subdirectory in the main web tree, and
+		the tilde construct points there.
 
-		   The prefix could be something like "users", or it could be empty.
+		The prefix could be something like "users", or it could be empty.
 
 config THTTPD_USE_TILDE_MAP2
 	bool "Tilde mapping 2"
@@ -241,8 +241,8 @@ config THTTPD_USE_TILDE_MAP2
 		an actual filename.  Choose this option for the second mapping:
 
 		2) Map ~username to <user's homedir>/<postfix>. The postfix would be
-		   the name of a subdirectory off of the user's actual home dir,
-		   something like "public_html".
+		the name of a subdirectory off of the user's actual home dir,
+		something like "public_html".
 
 		The typical value THTTPD_TILDE_MAP2 is "public_html". 
 
@@ -267,10 +267,10 @@ config THTTPD_TILDE_MAP1
 		for the first mapping:
 
 		1) Map ~username to <prefix>/username. This is the recommended
-		   choice. Each user gets a subdirectory in the main web tree, and
-		   the tilde construct points there.
+		choice. Each user gets a subdirectory in the main web tree, and
+		the tilde construct points there.
 
-		   The prefix could be something like "users", or it could be empty.
+		The prefix could be something like "users", or it could be empty.
 
 config THTTPD_TILDE_MAP2
 	string "Tilde mapping 2"
@@ -283,8 +283,8 @@ config THTTPD_TILDE_MAP2
 		for the second mapping:
 
 		2) Map ~username to <user's homedir>/<postfix>. The postfix would be
-		   the name of a subdirectory off of the user's actual home dir,
-		   something like "public_html".
+		the name of a subdirectory off of the user's actual home dir,
+		something like "public_html".
 
 		The typical value THTTPD_TILDE_MAP2 is "public_html". 
 
diff --git a/nuttx/Kconfig b/nuttx/Kconfig
index 1b8bc381e..f5b8de094 100644
--- a/nuttx/Kconfig
+++ b/nuttx/Kconfig
@@ -97,34 +97,32 @@ config APPS_DIR
 		directory and the NuttX directory each in separate directory
 		trees like this:
 
-		<pre>
-		build
-		|-nuttx
-		|  |
-		|  `- Makefile
-		`-application
-		|
-		`- Makefile
-		</pre>
+			build
+			|-nuttx
+			|  |
+			|  `- Makefile
+			`-application
+			|
+			`- Makefile
 		
 		Then you would set CONFIG_APPS_DIR=../application.
 
 		The application direction must contain Makefile and this make
 		file must support the following targets:
 		
-		libapps$(LIBEXT) (usually libapps.a). libapps.a is a static
+		1)libapps$(LIBEXT) (usually libapps.a). libapps.a is a static
 		library ( an archive) that contains all of application object
 		files.
 		
-		clean. Do whatever is appropriate to clean the application
+		2)clean. Do whatever is appropriate to clean the application
 		directories for a fresh build.
 		
-		distclean. Clean everthing -- auto-generated files, symbolic
+		3)distclean. Clean everthing -- auto-generated files, symbolic
 		links etc. -- so that the directory contents are the same as
 		the contents in your configuration management system.
 		This is only done when you change the NuttX configuration.
 		
-		depend. Make or update the application build dependencies.
+		4)depend. Make or update the application build dependencies.
 		
 		When this application is invoked it will receive the setting TOPDIR like:
 		
@@ -240,13 +238,11 @@ config ARCH_STDBOOL_H
 		However, that header includes logic to redirect the inclusion of an
 		architecture specific header file like:
 
-		<pre>
-		#ifdef CONFIG_ARCH_STDBOOL_H
-		#  include <arch/stdbool.h>
-		#else
-		...
-		#endif
-		</pre>
+			#ifdef CONFIG_ARCH_STDBOOL_H
+			#  include <arch/stdbool.h>
+			#else
+			...
+			#endif
 
 		Recall that that include path, include/arch, is a symbolic link and
 		will refer to a version of stdbool.h at nuttx/arch/<architecture>/include/stdbool.h.
@@ -259,15 +255,13 @@ config ARCH_MATH_H
 		However, it resides out-of-the-way at include/nuttx/math.h because it
 		conflicts too often with the system math.h. If ARCH_MATH_H=y is
 		defined, however, the top-level makefile will copy the redirecting
- 		math.h header file from include/nuttx/math.h to include/math.h. math.h
+		math.h header file from include/nuttx/math.h to include/math.h. math.h
 		will then include the architecture-specific version of math.h that you
 		must provide at nuttx/arch/>architecture</include/math.h.
 
-		<pre>
-		#ifdef CONFIG_ARCH_MATH_H
-		#  include <arch/math.h>
-		#endif
-		</pre>
+			#ifdef CONFIG_ARCH_MATH_H
+			#  include <arch/math.h>
+			#endif
 
 		So for the architectures that define ARCH_MATH_H=y, include/math.h
 		will be the redirecting math.h header file; for the architectures
@@ -282,7 +276,7 @@ config ARCH_FLOAT_H
 		point implementation.  It would always be best to use your
 		toolchain's float.h header file but if none is avaiable, a default
 		float.h header file will provided if this option is selected.  However
- 		there is no assurance that the settings in this float.h are actually
+		there is no assurance that the settings in this float.h are actually
 		correct for your platform!
 
 config ARCH_STDARG_H
diff --git a/nuttx/arch/arm/Kconfig b/nuttx/arch/arm/Kconfig
index c9b655d3a..a512edf25 100644
--- a/nuttx/arch/arm/Kconfig
+++ b/nuttx/arch/arm/Kconfig
@@ -188,7 +188,7 @@ config ARMV7M_USEBASEPRI
 	depends on ARCH_CORTEXM3 || ARCH_CORTEXM4
 	---help---
 		Use the BASEPRI register to enable and disable able interrupts.  By
- 		default, the PRIMASK register is used for this purpose.  This
+		default, the PRIMASK register is used for this purpose.  This
 		usually results in hardfaults that are properly handling by the
 		RTOS.  Using the BASEPRI register will avoid these hardfault.
 		That is needed primarily for integration with some toolchains.
diff --git a/nuttx/arch/arm/src/lpc17xx/Kconfig b/nuttx/arch/arm/src/lpc17xx/Kconfig
index e4a3913b1..6f8967054 100644
--- a/nuttx/arch/arm/src/lpc17xx/Kconfig
+++ b/nuttx/arch/arm/src/lpc17xx/Kconfig
@@ -540,7 +540,7 @@ config SDIO_WIDTH_D1_ONLY
 	---help---
 		Select 1-bit transfer mode.  This may be selected to force the driver
 		operate with only a single data line (the default is to use all
- 		4 SD data lines).Default: 4-bit transfer mode.
+		4 SD data lines).Default: 4-bit transfer mode.
 
 endmenu
 
diff --git a/nuttx/arch/mips/src/pic32mx/Kconfig b/nuttx/arch/mips/src/pic32mx/Kconfig
index 6ac10608b..bc22080eb 100644
--- a/nuttx/arch/mips/src/pic32mx/Kconfig
+++ b/nuttx/arch/mips/src/pic32mx/Kconfig
@@ -1076,8 +1076,8 @@ config PIC32MX_FETHIO
 	---help---
 		Ethernet I/O Pin Selection bit:
 
-			1 = Default Ethernet I/O Pins
-			0 = Alternate Ethernet I/O Pins
+		1 = Default Ethernet I/O Pins
+		0 = Alternate Ethernet I/O Pins
 
 config PIC32MX_FMIIEN
 	int "Ethernet MII"
@@ -1085,8 +1085,8 @@ config PIC32MX_FMIIEN
 	---help---
 		Ethernet MII Enable bit
 
-			1 = MII enabled
-			0 = RMII enabled
+		1 = MII enabled
+		0 = RMII enabled
 
 endmenu
 
diff --git a/nuttx/arch/z80/src/z180/Kconfig b/nuttx/arch/z80/src/z180/Kconfig
index 160c66b50..93291ead2 100644
--- a/nuttx/arch/z80/src/z180/Kconfig
+++ b/nuttx/arch/z80/src/z180/Kconfig
@@ -55,26 +55,26 @@ config Z180_BANKAREA_VIRTBASE
 
 		NuttX Memory Organization:
 
-			Common Area 0:  This area holds the common NuttX code that is
-			directly call-able from all application threads.  Common Area
-			always starts at virtual address 0x0000 and extends to the
-			Bank Area
-
-			Base Area: This area holds the common NuttX data (including the
-			share-able heap) that is accessible from all applications and
-			extends to Common Area 1.
-
-			NOTE:  That is execution from RAM, the common NuttX code and
-			data may be contiguous and lie in the same region (either
-			Common Area 0 or the Bank Area).  The two regions above would
-			apply in a ROM'ed system, where Common Area 1 is ROM and the
-			Base Area is RAM.
-
-			Common Area 1:  This area holds the code and data that is unique
-			to a particular task.  his area extends to the end of the virtual
-			address space.  All tasks share the same virtual Common Area 2
-			virtual address (but each has a unique mapping to different,
-			underlying physical addresses).
+		Common Area 0:  This area holds the common NuttX code that is
+		directly call-able from all application threads.  Common Area
+		always starts at virtual address 0x0000 and extends to the
+		Bank Area
+
+		Base Area: This area holds the common NuttX data (including the
+		share-able heap) that is accessible from all applications and
+		extends to Common Area 1.
+
+		NOTE:  That is execution from RAM, the common NuttX code and
+		data may be contiguous and lie in the same region (either
+		Common Area 0 or the Bank Area).  The two regions above would
+		apply in a ROM'ed system, where Common Area 1 is ROM and the
+		Base Area is RAM.
+
+		Common Area 1:  This area holds the code and data that is unique
+		to a particular task.  his area extends to the end of the virtual
+		address space.  All tasks share the same virtual Common Area 2
+		virtual address (but each has a unique mapping to different,
+		underlying physical addresses).
 
 config Z180_BANKAREA_PHYSBASE
 	hex "Physical Start of Bank Area"
@@ -93,26 +93,26 @@ config Z180_COMMON1AREA_VIRTBASE
 
 		NuttX Memory Organization:
 
-			Common Area 0:  This area holds the common NuttX code that is
-			directly call-able from all application threads.  Common Area
-			always starts at virtual address 0x0000 and extends to the
-			Bank Area
-
-			Base Area: This area holds the common NuttX data (including the
-			share-able heap) that is accessible from all applications and
-			extends to Common Area 1.
-
-			NOTE:  That is execution from RAM, the common NuttX code and
-			data may be contiguous and lie in the same region (either
-			Common Area 0 or the Bank Area).  The two regions above would
-			apply in a ROM'ed system, where Common Area 1 is ROM and the
-			Base Area is RAM.
-
-			Common Area 1:  This area holds the code and data that is unique
-			to a particular task.  his area extends to the end of the virtual
-			address space.  All tasks share the same virtual Common Area 2
-			virtual address (but each has a unique mapping to different,
-			underlying physical addresses).
+		Common Area 0:  This area holds the common NuttX code that is
+		directly call-able from all application threads.  Common Area
+		always starts at virtual address 0x0000 and extends to the
+		Bank Area
+
+		Base Area: This area holds the common NuttX data (including the
+		share-able heap) that is accessible from all applications and
+		extends to Common Area 1.
+
+		NOTE:  That is execution from RAM, the common NuttX code and
+		data may be contiguous and lie in the same region (either
+		Common Area 0 or the Bank Area).  The two regions above would
+		apply in a ROM'ed system, where Common Area 1 is ROM and the
+		Base Area is RAM.
+
+		Common Area 1:  This area holds the code and data that is unique
+		to a particular task.  his area extends to the end of the virtual
+		address space.  All tasks share the same virtual Common Area 2
+		virtual address (but each has a unique mapping to different,
+		underlying physical addresses).
 
 config Z180_PHYSHEAP_START
 	hex "Physical Start of Free Memory"
diff --git a/nuttx/configs/Kconfig b/nuttx/configs/Kconfig
index 090379988..16b41ba74 100644
--- a/nuttx/configs/Kconfig
+++ b/nuttx/configs/Kconfig
@@ -288,12 +288,12 @@ config ARCH_BOARD_NTOSD_DM320
 		This port uses the Neuros OSD v1.0 Dev Board with a GNU arm-nuttx-elf
 		toolchain*: see
 
-			http://wiki.neurostechnology.com/index.php/OSD_1.0_Developer_Home
+		http://wiki.neurostechnology.com/index.php/OSD_1.0_Developer_Home
 
 		There are some differences between the Dev Board and the currently
 		available commercial v1.0 Boards.  See
 
-			http://wiki.neurostechnology.com/index.php/OSD_Developer_Board_v1
+		http://wiki.neurostechnology.com/index.php/OSD_Developer_Board_v1
 
 		NuttX operates on the ARM9EJS of this dual core processor.
 		STATUS: This port is code complete, verified, and included in the
diff --git a/nuttx/libc/math/Kconfig b/nuttx/libc/math/Kconfig
index db9dfae63..7a322d760 100644
--- a/nuttx/libc/math/Kconfig
+++ b/nuttx/libc/math/Kconfig
@@ -18,7 +18,7 @@ config LIBM
 		Another possibility is that you have a custom, architecture-specific math
 		libary and that the corresponding math.h file resides at arch/<architecture>/include/math.h.
 		The option is selected via ARCH_MATH_H.  If ARCH_MATH_H is selected,then the include/nuttx/math.h
- 		header file will be copied to include/math.h where it can be used by your applications.
+		header file will be copied to include/math.h where it can be used by your applications.
 
 		If ARCH_MATH_H is not defined, then this option can be selected to build a generic,
 		math library built into NuttX.  This math library comes from the Rhombus OS and
diff --git a/nuttx/sched/Kconfig b/nuttx/sched/Kconfig
index b7561ff58..e461b704b 100644
--- a/nuttx/sched/Kconfig
+++ b/nuttx/sched/Kconfig
@@ -11,15 +11,15 @@ config BOARD_INITIALIZE
 		custom initialization logic:
 
 		1) <arch>_boardinitialize():  This function is used only for
-		   initialize of very low-level things like configuration of
-		   GPIO pins, power setting.  The OS has not been initialized
-		   at this point, so you cannot allocate memory or initialize
-		   device drivers at this phase.
+		initialize of very low-level things like configuration of
+		GPIO pins, power setting.  The OS has not been initialized
+		at this point, so you cannot allocate memory or initialize
+		device drivers at this phase.
 
 		2) The next level of initialization is performed by a call to
-		   up_initialize() (in arch/<arch>/src/common/up_initialize.c).
-		   The OS has been initialized at this point and it is okay to
-		   initialize drivers in this phase.
+		up_initialize() (in arch/<arch>/src/common/up_initialize.c).
+		The OS has been initialized at this point and it is okay to
+		initialize drivers in this phase.
 
 		3) And, finally, when the user application code starts.
 
@@ -88,8 +88,8 @@ config SCHED_CHILD_STATUS
 		Without this setting, wait(), waitpid() or waitid() may fail.  For
 		example, if you do:
 
-			1) Start child task
-			2) Wait for exit status (using wait(), waitpid(), or waitid()).
+		1) Start child task
+		2) Wait for exit status (using wait(), waitpid(), or waitid()).
 
 		This can fail because the child task may run to completion before
 		the wait begins.  There is a non-standard work-around in this case:
@@ -317,19 +317,19 @@ config DISABLE_OS_API
 	bool "Disable NuttX interfaces"
 	default y
 	---help---
-	The following can be used to disable categories of
-	APIs supported by the OS.  If the compiler supports
-	weak functions, then it should not be necessary to
-	disable functions unless you want to restrict usage
-	of those APIs.
+		The following can be used to disable categories of
+		APIs supported by the OS.  If the compiler supports
+		weak functions, then it should not be necessary to
+		disable functions unless you want to restrict usage
+		of those APIs.
 
-	There are certain dependency relationships in these
-	features.
+		There are certain dependency relationships in these
+		features.
 
-	o mq_notify logic depends on signals to awaken tasks
-	  waiting for queues to become full or empty.
-	o pthread_condtimedwait() depends on signals to wake
-	  up waiting tasks.
+		1) mq_notify logic depends on signals to awaken tasks
+		waiting for queues to become full or empty.
+		2) pthread_condtimedwait() depends on signals to wake
+		up waiting tasks.
 
 config DISABLE_CLOCK
 	bool "Disable clock interfaces"
@@ -478,7 +478,7 @@ config PREALLOC_WDOGS
 	---help---
 		The number of pre-allocated watchdog structures.  The system manages a
 		pool of preallocated watchdog structures to minimize dynamic allocations
-	
+
 config PREALLOC_TIMERS
 	int "Number of pre-allocated POSIX timers"
 	default 8
@@ -516,4 +516,3 @@ config PTHREAD_STACK_DEFAULT
 	default 2048
 	---help---
 		Default pthread stack size
-
diff --git a/nuttx/tools/kconfig2html.c b/nuttx/tools/kconfig2html.c
index 05e09663d..dc22e7efb 100644
--- a/nuttx/tools/kconfig2html.c
+++ b/nuttx/tools/kconfig2html.c
@@ -1100,10 +1100,13 @@ static inline void process_help(FILE *stream)
   bool blank;
   bool done;
   bool newpara;
+  bool preformatted;
 
   /* Read each comment line */
 
   newpara = true;
+  preformatted = false;
+
   for (;;)
    {
       /* Read the next line of comment text */
@@ -1165,7 +1168,7 @@ static inline void process_help(FILE *stream)
 
           if (!newpara)
             {
-              body("</p>\n");
+              body("\n</p>\n");
               newpara = true;
             }
 
@@ -1193,16 +1196,45 @@ static inline void process_help(FILE *stream)
 
       if (newpara)
         {
-          body("</p>\n");
+          body("<p>\n");
           newpara = false;
         }
 
-      body("  %s", htmlize_text(ptr));
+      /* Lines that are indented at greater levels are assumed to be
+       * pre-formatted text.  This is not part of the Kconfig language but
+       * rather simply a NuttX Kconfig convention.
+       */
+
+      if (indent > help_indent)
+        {
+          if (!preformatted)
+            {
+              body("\n  <ul><pre>\n");
+              preformatted = true;
+            }
+
+          body("%s\n", htmlize_text(ptr));
+        }
+      else
+        {
+          if (preformatted)
+            {
+              body("</pre></ul>\n");
+              preformatted = false;
+            }
+
+          body("  %s", htmlize_text(ptr));
+        }
     }
 
   if (!newpara)
     {
-      body("</p>\n");
+      body("\n</p>\n");
+    }
+
+  if (preformatted)
+    {
+      body("</pre></ul>\n");
     }
 }
 
@@ -1761,7 +1793,7 @@ static inline char *process_choice(FILE *stream, const char *kconfigdir)
   const char *paranum;
   char *token = NULL;
   char *ptr;
-  bool help;
+  bool help = false;
   int i;
 
   /* Get the choice information */