mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Remy Bohmer" <linux@bohmer.net>
To: "Randy Dunlap" <randy.dunlap@oracle.com>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
	"Arnaldo Carvalho de Melo" <acme@ghostprotocols.net>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Juergen Beisert" <jbe@pengutronix.de>,
	"Darren Hart" <dvhltc@us.ibm.com>,
	linux-rt-users@vger.kernel.org,
	"Sven-Thorsten Dietrich" <sdietrich@novell.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)
Date: Wed, 19 Dec 2007 22:44:10 +0100	[thread overview]
Message-ID: <3efb10970712191344l7656f2b3m8d9fbde193f39eaa@mail.gmail.com> (raw)
In-Reply-To: <20071219130059.d99489d1.randy.dunlap@oracle.com>

Hello Randy,

Sorry for the language errors, English is not my Native language, so I
make these stupid errors...

> > + *   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.

OK, I will adapt that.

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

I know it is big on a 4k stack, and I also think it is not very nice...
But kmalloc() panics the kernel if I do it as soon as in the __setup() code.

The problem is that the original string may not be modified by the
cmdline-parser, and I do not know the length of the command up front,
(except that it cannot be longer than this define). Allocating a
global buffer is not safe and needs locking. So actually only what
left for me was the stack... or rewrite the used C-library-routines
completely myself, for this purpose only, which is also not nice.

I hope someone could point to me to another possibilty, that I did not
think of yet.


Kind Regards,

Remy

>
> > +     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++;
> > +                                             sscanf(substr, "%d", pint);
> > +                                             found = 1;
> > +                                     }
> > +                             }
> > +                     }
> > +             }
> > +             substr = strsep(&p, ",");
> > +     }
> > +     return found;
> > +}
>
> ---
> ~Randy
>

  reply	other threads:[~2007-12-19 21:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20071219194551.315868746@bohmer.net>
2007-12-19 19:45 ` Remy Bohmer
2007-12-19 21:00   ` Randy Dunlap
2007-12-19 21:44     ` Remy Bohmer [this message]
2007-12-19 19:45 ` [patch 2/3] Enable setting of IRQ-thread priorities from kernel cmdline " Remy Bohmer
2007-12-19 20:51   ` Randy Dunlap
2007-12-20 12:02   ` Jaswinder Singh
2007-12-19 19:45 ` [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. " Remy Bohmer
2007-12-19 20:55   ` Randy Dunlap
2007-12-20 11:59   ` Jaswinder Singh
2007-12-20 12:25     ` Remy Bohmer
2007-12-20 12:45       ` Jaswinder Singh
2007-12-20 12:50         ` Remy Bohmer
2007-12-20 13:18         ` Juergen Beisert
2007-12-20 13:40           ` Jaswinder Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3efb10970712191344l7656f2b3m8d9fbde193f39eaa@mail.gmail.com \
    --to=linux@bohmer.net \
    --cc=acme@ghostprotocols.net \
    --cc=dvhltc@us.ibm.com \
    --cc=jbe@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=randy.dunlap@oracle.com \
    --cc=rostedt@goodmis.org \
    --cc=sdietrich@novell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®