[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A5AA0AD.2030502@impulze.org>
Date: Mon, 13 Jul 2009 04:49:17 +0200
From: Daniel Mierswa <impulze@...ulze.org>
To: Rusty Russell <rusty@...tcorp.com.au>
CC: linux-kernel@...r.kernel.org
Subject: Re: [RFC] Re: Parsing kernel parameters and escaping "
Rusty Russell wrote:
> It might be nice to have that test code somewhere at the bottom of param.c,
> at least while we're playing with the code.
Umm, I'm not sure where test-code is supposed to go in kernel code.
Should it be a main() function, a test() function, just a comment, could
you elaborate? All i did now was to build a small program that reads
argv[1] and uses next_arg just like parse_args() in params.c does.
> Well, IMO it's a maintainer's job to give feedback, and patches should always be welcomed (even if not applied!).
Ok, we'll see where this goes. So far I'm fine chatting about this with
everyone.
> I really prefer "i" instead of "iterator". I actually think i as an
> unsigned/size_t here would probably make the code neater, but that's an aside.
Fixed.
> memmove?
Fixed.
> How about:
> if (strchr(delim, *iterator))
> return length;
I really should do more C. :-P Fixed.
> Note that this will undo another pending patch, which changes this to
> isspace() to handle tabs et al.
I will re-do the patch against that commit then once it's done.
> Thanks!
Ditto.
--
Mierswa, Daniel
If you still don't like it, that's ok: that's why I'm boss. I simply
know better than you do.
--- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22
View attachment "kernel2.patch" of type "text/plain" (3798 bytes)
Powered by blists - more mailing lists