From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW3oR-0003MT-4r for qemu-devel@nongnu.org; Thu, 01 Dec 2011 05:24:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RW3oQ-00083O-1z for qemu-devel@nongnu.org; Thu, 01 Dec 2011 05:24:19 -0500 Received: from mail-bw0-f45.google.com ([209.85.214.45]:54782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW3oP-00083K-Ob for qemu-devel@nongnu.org; Thu, 01 Dec 2011 05:24:17 -0500 Received: by bkar19 with SMTP id r19so2570914bka.4 for ; Thu, 01 Dec 2011 02:24:16 -0800 (PST) Date: Thu, 1 Dec 2011 10:24:13 +0000 From: Stefan Hajnoczi Message-ID: <20111201102413.GA31730@stefanha-thinkpad.localdomain> References: <1322687028-29714-1-git-send-email-aliguori@us.ibm.com> <1322687028-29714-6-git-send-email-aliguori@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1322687028-29714-6-git-send-email-aliguori@us.ibm.com> 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: Anthony Liguori Cc: Kevin Wolf , Peter Maydell , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino 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. > +/** > + * @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. > + * > + * Returns: > + * The matched device. The matched device or NULL on path lookup failure.