From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35779 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PoMa4-0003RB-UA
	for qemu-devel@nongnu.org; Sat, 12 Feb 2011 16:00:37 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1PoMa3-00079p-Sg
	for qemu-devel@nongnu.org; Sat, 12 Feb 2011 16:00:36 -0500
Received: from gate.crashing.org ([63.228.1.57]:55922)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1PoMa3-00079c-Hw
	for qemu-devel@nongnu.org; Sat, 12 Feb 2011 16:00:35 -0500
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
In-Reply-To: <AANLkTimYxXeBuKmXKdv=ENu4ZZyDK=CEv+et568ga1Qk@mail.gmail.com>
References: <1297522467-5975-1-git-send-email-david@gibson.dropbear.id.au>
	<1297522467-5975-16-git-send-email-david@gibson.dropbear.id.au>
	<1BA55C28-0AAF-46A5-A14F-04B0B61419DB@suse.de>
	<AANLkTimYxXeBuKmXKdv=ENu4ZZyDK=CEv+et568ga1Qk@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 13 Feb 2011 08:00:24 +1100
Message-ID: <1297544424.14982.628.camel@pasglop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR
	virtual IO
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: "qemu-devel@nongnu.org List" <qemu-devel@nongnu.org>, Paul Mackerras <paulus@samba.org>, Alexander Graf <agraf@suse.de>, anton@samba.org, David Gibson <david@gibson.dropbear.id.au>

On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
> 
> Actually I don't quite understand the need for vty layer, why not use
> the chardev here directly?

I'm not sure what you mean here...

Basically, the interface presented to guests is sPAPR compliant, so
virtual devices come with a bunch of stuff such as standard device-tree
properties, but also hcalls for interrupt control etc... which are
common to most of these guys including vty.

Some of it isn't present in David current patch just yet, but I don't
see how using an existing chardev would provide the same semantics,
especially when we start adding interrupts etc...

Also eventually, VTY's will be hot-pluggable (when we get to do that)
and will use the same mechanisms as the other sPAPR VIO devices for
that.

Cheers,
Ben.