From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW6mt-00081A-5F for qemu-devel@nongnu.org; Thu, 01 Dec 2011 08:34:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RW6ml-00009A-9d for qemu-devel@nongnu.org; Thu, 01 Dec 2011 08:34:54 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:39037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW6ml-000096-7B for qemu-devel@nongnu.org; Thu, 01 Dec 2011 08:34:47 -0500 Received: by ggnk1 with SMTP id k1so258750ggn.4 for ; Thu, 01 Dec 2011 05:34:46 -0800 (PST) Message-ID: <4ED78273.1070109@codemonkey.ws> Date: Thu, 01 Dec 2011 07:34:43 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1322687028-29714-1-git-send-email-aliguori@us.ibm.com> <1322687028-29714-6-git-send-email-aliguori@us.ibm.com> <20111201102413.GA31730@stefanha-thinkpad.localdomain> In-Reply-To: <20111201102413.GA31730@stefanha-thinkpad.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 05/18] qdev: provide a path resolution List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Peter Maydell , Anthony Liguori , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino On 12/01/2011 04:24 AM, Stefan Hajnoczi wrote: > On Wed, Nov 30, 2011 at 03:03:35PM -0600, Anthony Liguori wrote: >> +DeviceState *qdev_resolve_path(const char *path, bool *ambiguous) >> +{ >> + bool partial_path = true; >> + DeviceState *dev; >> + gchar **parts; >> + >> + parts = g_strsplit(path, "/", 0); >> + if (parts == NULL || parts[0] == NULL) { > > We must g_strfreev(parts) in the parts[0] == NULL case. Good catch! > >> +/** >> + * @qdev_resolve_path - resolves a path returning a device >> + * >> + * There are two types of supported paths--absolute paths and partial paths. >> + * >> + * Absolute paths are derived from the root device and can follow child<> or >> + * link<> properties. Since they can follow link<> properties, they can be >> + * arbitrarily long. Absolute paths look like absolute filenames and are prefix > > s/prefix/prefixed/ > >> + * with a leading slash. >> + * >> + * Partial paths are look like relative filenames. They do not begin with a > > s/are// > >> + * prefix. The matching rules for partial paths are subtle but designed to make >> + * specifying devices easy. At each level of the composition tree, the partial >> + * path is matched as an absolute path. The first match is not returned. At >> + * least two matches are searched for. A successful result is only returned if >> + * only one match is founded. If more than one match is found, a flag is return > > s/return/returned/ > >> + * to indicate that the match was ambiguous. >> + * >> + * @path - the path to resolve >> + * >> + * @ambiguous - returns true if the path resolution failed because of an >> + * ambiguous match > > The implementation seems to depend on ambiguous being initialized to > false by the caller. That would be worth documenting or changing so it > does not depend on the initial value. That's actually a bug. I'll fix it. Ack on the other comments too. Regards, Anthony Liguori > >> + * >> + * Returns: >> + * The matched device. > > The matched device or NULL on path lookup failure. >