Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

This patch adds a generic routine to the kernel, so that a map of settings can be entered on the kernel commandline.

Signed-off-by Remy Bohmer <[email protected]>

---

---
 include/linux/kernel.h |    1 
 lib/cmdline.c          |   58 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+)

Index: linux-2.6.24-rc5-rt1/lib/cmdline.c
===================================================================

lib/cmdline.c +8 -0

+ *
+ *	This function parses an integer from an option map like
+ *           some_map=key1:99,key2:98,...,keyN:NN,NN
+ *	Only the value of the first match is returned, or if no
+ *	key option is given (key = NULL) the value of the first
+ *	field without a ':' is returned.
+ *
+ *	@str: option string

lib/cmdline.c +26 -0

+	char  *p, *substr;
+	int   found = 0;
+
+	/* We must copy the string to the stack, because strsep()
+	   changes it.*/
+	strncpy(buf, str, COMMAND_LINE_SIZE);
+	buf[COMMAND_LINE_SIZE-1] = '\0';
+
+	p = buf;
+	substr = strsep(&p, ",");
+	while ((!found) && (substr != NULL)) {
+		if (strlen(substr) != 0) {
+			if (key == NULL) {
+				/* Check for the absence of any ':' */
+				if (strchr(substr, ':') == NULL) {
+					sscanf(substr, "%d", pint);
+					found = 1;
+				}
+			} else {
+				/* check if the first part of the key matches */
+				if (!strncmp(substr, key, strlen(key))) {
+					substr += strlen(key);
+					/* Now the next char must be a ':',
+					   if not, search for the next match */
+					if (*substr == ':') {
+						substr++;

Quoted 1 line

+ * get_map_option - Parse integer from an option map

The @param lines (below) need to go here, immediately following the function short description (the line above). No intervening blank lines.

lib/cmdline.c char *get_options(const char *str, int n · line 136

Quoted 3 lines

lib/cmdline.c +3 -0

+int get_map_option(const char *str, const char *key, int *pint)
+{
+     char  buf[COMMAND_LINE_SIZE];

COMMAND_LINE_SIZE varies from 256 to 2048, depending on $ARCH. That's a bit too much to declare on a function's local stack -- unless you are very certain of the call tree to this point and that the total stack size is safe. Can you just kmalloc() this buf?

Quoted 27 lines

lib/cmdline.c +26 -0

+     char  *p, *substr;
+     int   found = 0;
+
+     /* We must copy the string to the stack, because strsep()
+        changes it.*/
+     strncpy(buf, str, COMMAND_LINE_SIZE);
+     buf[COMMAND_LINE_SIZE-1] = '\0';
+
+     p = buf;
+     substr = strsep(&p, ",");
+     while ((!found) && (substr != NULL)) {
+             if (strlen(substr) != 0) {
+                     if (key == NULL) {
+                             /* Check for the absence of any ':' */
+                             if (strchr(substr, ':') == NULL) {
+                                     sscanf(substr, "%d", pint);
+                                     found = 1;
+                             }
+                     } else {
+                             /* check if the first part of the key matches */
+                             if (!strncmp(substr, key, strlen(key))) {
+                                     substr += strlen(key);
+                                     /* Now the next char must be a ':',
+                                        if not, search for the next match */
+                                     if (*substr == ':') {
+                                             substr++;

lib/cmdline.c char *get_options(const char *str, int n · line 172

Quoted 10 lines

lib/cmdline.c +10 -0

+                                             sscanf(substr, "%d", pint);
+                                             found = 1;
+                                     }
+                             }
+                     }
+             }
+             substr = strsep(&p, ",");
+     }
+     return found;
+}

---
~Randy

 Documentation/kernel-parameters.txt |    7 ++
 include/linux/irq.h                 |    1 
 kernel/irq/manage.c                 |  101 ++++++++++++++++++++++++++++++++----
 3 files changed, 98 insertions(+), 11 deletions(-)

Index: linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt
===================================================================

Documentation/kernel-parameters.txt +2 -0

+			runs at prio 50.
+
 	ports=		[IP_VS_FTP] IPVS ftp helper module
 			Default is 21.
 			Up to 8 (IP_VS_APP_MAX_PORTS) ports

Index: linux-2.6.24-rc5-rt1/kernel/irq/manage.c
===================================================================

 Documentation/kernel-parameters.txt |   11 +++
 kernel/softirq.c                    |  105 ++++++++++++++++++++++++++++++------
 2 files changed, 99 insertions(+), 17 deletions(-)

Index: linux-2.6.24-rc5-rt1/Documentation/kernel-parameters.txt
===================================================================

Documentation/kernel-parameters.txt +2 -0

+			runs at prio 50.
+
 	ports=		[IP_VS_FTP] IPVS ftp helper module
 			Default is 21.
 			Up to 8 (IP_VS_APP_MAX_PORTS) ports

Index: linux-2.6.24-rc5-rt1/kernel/softirq.c
===================================================================

kernel/softirq.c +5 -0

+ * prio is returned, which is either MAX_PRIO/2, or the default given on the
+ * kernel commandline.
+ */
+static int get_softirq_prio(const char *name)
+{

+}

The RT-patch originally creates all its softirq-threads at priority 50.

Is it possible to run softirq-threads or IRQs as a non-realtime tasks in RT kernel.

Quoted 2 lines

The RT-patch originally creates all its softirq-threads at priority 50.

Is it possible to run softirq-threads or IRQs as a non-realtime tasks in RT kernel.

If yes, then how.

Thank you,

Jaswinder Singh.

So, Is this a serious requirement? Should this be possible?

By default, all softirq-threads or IRQs will be RT task but if there is some option user can switch it to NON-RT task then it will be good.

Hello Remy,

Quoted 1 line · Remy Bohmer

So, Is this a serious requirement? Should this be possible?

I have noticed this problem:

[email protected]:~# cat /proc/loadavgrt
1.00 1.00 1.00 0/52 1158
[email protected]:~# cat /proc/loadavg
0.00 0.00 0.02 1/52 1159
[email protected]:~#

So I am curious, if possible, user can switch softirq-threads or IRQs RT tasks to non-RT tasks for slow hardware or least important hardware for NON-RT tasks. So this will improve RT behaviour.

By default, all softirq-threads or IRQs will be RT task but if there is some option user can switch it to NON-RT task then it will be good.

Thank you,

Jaswinder Singh.

Quoted 1 line · Remy Bohmer

So, Is this a serious requirement? Should this be possible?

I have noticed this problem:

[email protected]:~# cat /proc/loadavgrt
1.00 1.00 1.00 0/52 1158
[email protected]:~# cat /proc/loadavg
0.00 0.00 0.02 1/52 1159
[email protected]:~#

So I am curious, if possible, user can switch softirq-threads or IRQs RT tasks to non-RT tasks for slow hardware or least important hardware for NON-RT tasks. So this will improve RT behaviour.

Quoted 3 lines · Jaswinder Singh

So I am curious, if possible, user can switch softirq-threads or IRQs RT tasks to non-RT tasks for slow hardware or least important hardware for NON-RT tasks. So this will improve RT behaviour.

                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why?

IMHO: Simply decrease the RT priority of less important IRQs or increase all other more important IRQs. IRQs are always more important than other processes in a system, also in non RT systems.

Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9