From: Rusty Russell <rusty@rustcorp.com.au>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Sasha Levin <levinsasha928@gmail.com>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH] virtio-mmio: Devices parameter parsing
Date: Tue, 22 Nov 2011 11:14:18 +1030 [thread overview]
Message-ID: <87ipmdx9y5.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1321886688.3093.248.camel@hornet.cambridge.arm.com>
On Mon, 21 Nov 2011 14:44:48 +0000, Pawel Moll <pawel.moll@arm.com> wrote:
> On Mon, 2011-11-21 at 03:32 +0000, Rusty Russell wrote:
> > 2) Doesn't leak mem on error paths.
>
> Em, I don't think my code was leaking memory in any error case? (no
> offence meant or taken ;-)
You're right, I'm wrong. In your original version, your innovative use
of free() then strdup() worked as intended.
> > 3) Handles error from platform_device_register_resndata().
>
> As my code was ignoring wrong descriptions (all the continues) I ignored
> this result as well (the implementation complains on its own anyway),
> but I get your point.
I was referring to this:
return platform_device_register_resndata(&virtio_mmio_cmdline_parent,
"virtio-mmio", virtio_mmio_cmdline_id++,
resources, ARRAY_SIZE(resources), NULL, 0) != NULL;
The set function returns 0 or a -ve errno, not true/false.
> > 4) Uses shorter names for static functions/variables.
>
> Ah, I get the hint :-) I'm trying to keep the naming convention in
> static symbols as well, as it makes cscope/ctags/grep usage easier...
> I'll just use the abbreviated "vm_" prefixes then.
>
> > See what you think...
>
> Funnily enough when I proposed some string parser few years ago (totally
> different story) I was flamed for using strchr() instead of strsep() ;-)
> But ok, I don't mind getting back to basics.
>
> > +static int set_cmdline_device(const char *device, const struct kernel_param *kp)
> [...]
> > + delim = strchr(device, '@');
> [...]
> > + *delim = '\0';
>
> Ah. I forgot that strchr() takes const char * but returns "non-const"
> char *... Cheating, that's what it is ;-), but will work. Probably what
> we really want is something like
> kstrtoull_delim(device, 0, &val, "@\0")
> I'll have a look and may try to propose something of that sort, but
> that's another story. Maybe I should just use simple_strtol() for the
> time being?
Or would it be simpler to enhance sscanf() with some weird format option
for suffixing? I haven't looked for similar cases, but I'd suspect a
big win in general.
This would be neater than anything else we've got:
if (sscanf(device, "%llu@%llu[KMG]:%u", ...) != 3
&& sscanf(device, "%llu@%llu[KMG]:%u:%u", ...) != 4)
return -EINVAL;
Cheers,
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Pawel Moll <pawel.moll@arm.com>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtualization\@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
Sasha Levin <levinsasha928@gmail.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH] virtio-mmio: Devices parameter parsing
Date: Tue, 22 Nov 2011 11:14:18 +1030 [thread overview]
Message-ID: <87ipmdx9y5.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1321886688.3093.248.camel@hornet.cambridge.arm.com>
On Mon, 21 Nov 2011 14:44:48 +0000, Pawel Moll <pawel.moll@arm.com> wrote:
> On Mon, 2011-11-21 at 03:32 +0000, Rusty Russell wrote:
> > 2) Doesn't leak mem on error paths.
>
> Em, I don't think my code was leaking memory in any error case? (no
> offence meant or taken ;-)
You're right, I'm wrong. In your original version, your innovative use
of free() then strdup() worked as intended.
> > 3) Handles error from platform_device_register_resndata().
>
> As my code was ignoring wrong descriptions (all the continues) I ignored
> this result as well (the implementation complains on its own anyway),
> but I get your point.
I was referring to this:
return platform_device_register_resndata(&virtio_mmio_cmdline_parent,
"virtio-mmio", virtio_mmio_cmdline_id++,
resources, ARRAY_SIZE(resources), NULL, 0) != NULL;
The set function returns 0 or a -ve errno, not true/false.
> > 4) Uses shorter names for static functions/variables.
>
> Ah, I get the hint :-) I'm trying to keep the naming convention in
> static symbols as well, as it makes cscope/ctags/grep usage easier...
> I'll just use the abbreviated "vm_" prefixes then.
>
> > See what you think...
>
> Funnily enough when I proposed some string parser few years ago (totally
> different story) I was flamed for using strchr() instead of strsep() ;-)
> But ok, I don't mind getting back to basics.
>
> > +static int set_cmdline_device(const char *device, const struct kernel_param *kp)
> [...]
> > + delim = strchr(device, '@');
> [...]
> > + *delim = '\0';
>
> Ah. I forgot that strchr() takes const char * but returns "non-const"
> char *... Cheating, that's what it is ;-), but will work. Probably what
> we really want is something like
> kstrtoull_delim(device, 0, &val, "@\0")
> I'll have a look and may try to propose something of that sort, but
> that's another story. Maybe I should just use simple_strtol() for the
> time being?
Or would it be simpler to enhance sscanf() with some weird format option
for suffixing? I haven't looked for similar cases, but I'd suspect a
big win in general.
This would be neater than anything else we've got:
if (sscanf(device, "%llu@%llu[KMG]:%u", ...) != 3
&& sscanf(device, "%llu@%llu[KMG]:%u:%u", ...) != 4)
return -EINVAL;
Cheers,
Rusty.
next prev parent reply other threads:[~2011-11-22 0:44 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-15 13:53 [PATCH] virtio-mmio: Devices parameter parsing Pawel Moll
2011-11-16 0:42 ` Rusty Russell
2011-11-16 0:42 ` Rusty Russell
2011-11-16 18:13 ` Pawel Moll
2011-11-16 18:13 ` Pawel Moll
2011-11-17 12:42 ` [PATCH v2] " Pawel Moll
2011-11-17 12:42 ` Pawel Moll
2011-11-21 3:32 ` [PATCH] " Rusty Russell
2011-11-21 14:44 ` Pawel Moll
2011-11-21 14:44 ` Pawel Moll
2011-11-21 17:56 ` Pawel Moll
2011-11-21 17:56 ` Pawel Moll
2011-11-22 0:53 ` Rusty Russell
2011-11-22 0:53 ` Rusty Russell
2011-11-23 18:08 ` Pawel Moll
2011-11-28 0:31 ` Rusty Russell
2011-11-28 0:31 ` Rusty Russell
2011-11-29 17:36 ` Pawel Moll
2011-11-29 17:36 ` Pawel Moll
2011-12-01 2:06 ` Rusty Russell
2011-12-01 2:06 ` Rusty Russell
2011-12-12 17:53 ` Pawel Moll
2011-12-12 17:53 ` Pawel Moll
2011-12-12 17:57 ` [PATCH 1/2] params: <level>_initcall-like kernel parameters Pawel Moll
2011-12-12 17:57 ` Pawel Moll
2011-12-12 17:57 ` [PATCH 2/2] virtio-mmio: Devices parameter parsing Pawel Moll
2011-12-12 17:57 ` Pawel Moll
2012-04-09 16:32 ` Sasha Levin
2012-04-09 16:32 ` Sasha Levin
2012-04-10 12:53 ` Pawel Moll
2012-04-10 12:53 ` Pawel Moll
2011-12-15 3:51 ` [PATCH 1/2] params: <level>_initcall-like kernel parameters Rusty Russell
2011-12-15 3:51 ` Rusty Russell
2011-12-15 9:38 ` Pawel Moll
2011-12-15 9:38 ` Pawel Moll
2011-11-22 0:44 ` Rusty Russell [this message]
2011-11-22 0:44 ` [PATCH] virtio-mmio: Devices parameter parsing Rusty Russell
2011-11-21 3:32 ` Rusty Russell
-- strict thread matches above, loose matches on Subject: below --
2011-11-15 13:53 Pawel Moll
2012-05-09 17:30 Pawel Moll
2012-05-09 17:30 ` Pawel Moll
2012-05-10 0:44 ` Rusty Russell
2012-05-10 0:44 ` Rusty Russell
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=87ipmdx9y5.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pawel.moll@arm.com \
--cc=peter.maydell@linaro.org \
--cc=virtualization@lists.linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.