From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Myn7u-00034H-Dm for qemu-devel@nongnu.org; Fri, 16 Oct 2009 09:45:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Myn7n-00031w-7G for qemu-devel@nongnu.org; Fri, 16 Oct 2009 09:45:49 -0400 Received: from [199.232.76.173] (port=53845 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Myn7l-00031H-IA for qemu-devel@nongnu.org; Fri, 16 Oct 2009 09:45:41 -0400 Received: from mail-qy0-f199.google.com ([209.85.221.199]:43881) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Myn7l-0008NB-AH for qemu-devel@nongnu.org; Fri, 16 Oct 2009 09:45:41 -0400 Received: by qyk37 with SMTP id 37so1337154qyk.18 for ; Fri, 16 Oct 2009 06:45:40 -0700 (PDT) Message-ID: <4AD87901.5030705@codemonkey.ws> Date: Fri, 16 Oct 2009 08:45:37 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1255037747-3340-1-git-send-email-lcapitulino@redhat.com> <1255037747-3340-2-git-send-email-lcapitulino@redhat.com> <4AD72B88.2040107@codemonkey.ws> <20091015122622.1f93ea2d@doriath> <20091015163936.GB532@redhat.com> <20091015142837.6c90580a@doriath> <4AD76B3C.3050001@codemonkey.ws> <4AD87424.3010000@redhat.com> In-Reply-To: <4AD87424.3010000@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, Luiz Capitulino Paolo Bonzini wrote: > It's 36k, and pulling it in gives the opportunity to customize it. > For example, the attached patch allows to parse a "%BLAH" extension to > JSON that is passed to the callback (since the parsing is done > character-by-character, the callback can consume whatever it wants > after the % sign). Asprintf+parse JSON unfortunately isn't enough > because you'd need to escape all strings. What's the state of this library's upstream? Should we be pushing these changes there and then attempting to package it? I'd rather pull this in a submodule, try to get it packaged properly, and then eventually drop the submodule. I don't want us to fork the library unless we have to. Regards, Anthony Liguori