From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48917) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qp0Z6-0007yr-Ns for qemu-devel@nongnu.org; Thu, 04 Aug 2011 12:14:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qp0Z5-0005wD-LI for qemu-devel@nongnu.org; Thu, 04 Aug 2011 12:14:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qp0Z5-0005w2-5G for qemu-devel@nongnu.org; Thu, 04 Aug 2011 12:14:31 -0400 Message-ID: <4E3AC561.7070902@redhat.com> Date: Thu, 04 Aug 2011 19:14:25 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1312208590-25502-1-git-send-email-aliguori@us.ibm.com> <1312208590-25502-2-git-send-email-aliguori@us.ibm.com> <4E3AC230.1070109@redhat.com> <4E3AC498.6000404@codemonkey.ws> In-Reply-To: <4E3AC498.6000404@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/12] char: rename qemu_chr_write() to qemu_chr_fe_write() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , Hans de Goede , qemu-devel@nongnu.org On 08/04/2011 07:11 PM, Anthony Liguori wrote: > On 08/04/2011 11:00 AM, Avi Kivity wrote: >> On 08/01/2011 05:22 PM, Anthony Liguori wrote: >>> The char layer is confusing. There is a front-end, typically a device, >>> that >>> can send and receive data. The front-end sends data by calling >>> qemu_chr_write(). >>> >>> The back-end, typically created via -chardev, can also send and >>> receive data. >>> Oddly, it sends data by calling qemu_chr_read(). >>> >>> Let's be explicit about which function is for which party. >> >> A different way to accomplish this would be to have each pipe expose two >> interfaces (a front end and a back end), and use the same functions for >> both. Just like a unix pipe. > > This is exactly what I'm trying to do. This is why I decided to do > this before QOM, because this will change the relationships between > objects dramatically since you no longer need to subclass > CharDriverState since it's just being used as a pipe. Yes, I'm just talking about the function names, not about the implementation. qemu_chr_fe_write(chr,...) -> qemu_chr_write(chr, ...) qemu_chr_be_write(chr, ...) -> qemu_chr_write(&chr->backend, ...) -- error compiling committee.c: too many arguments to function