From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MijRq-00018B-0U
	for qemu-devel@nongnu.org; Wed, 02 Sep 2009 02:36:02 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MijRl-00017z-7h
	for qemu-devel@nongnu.org; Wed, 02 Sep 2009 02:36:01 -0400
Received: from [199.232.76.173] (port=38919 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MijRl-00017w-1H
	for qemu-devel@nongnu.org; Wed, 02 Sep 2009 02:35:57 -0400
Received: from mx1.redhat.com ([209.132.183.28]:43597)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MijRk-0002eU-KB
	for qemu-devel@nongnu.org; Wed, 02 Sep 2009 02:35:56 -0400
Message-ID: <4A9E1247.9040009@redhat.com>
Date: Wed, 02 Sep 2009 08:35:51 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling
References: <f43fc5580908290706j6f38433akbb1d0dda0b5cf456@mail.gmail.com>
	<4A9B85E5.8040902@redhat.com>
	<f43fc5580908310823h3cdc5c0wbf805a16a66f0bf7@mail.gmail.com>
	<4A9CD334.6000407@redhat.com>
	<f43fc5580909010921y60cc632o637c65cd6e194dd2@mail.gmail.com>
In-Reply-To: <f43fc5580909010921y60cc632o637c65cd6e194dd2@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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.gnu.org/pipermail/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 <qemu-devel@nongnu.org>

   Hi,

>> drives are host side state, they don't go into qdev.
>
> My idea was that boards (like pc) should be in the long run
> represented by a qdev.

The qdev root is the main_system_bus right now, I don't see a need to 
change that.  All core devices (cpus, memory, pic, ...) can be children 
of the main system bus.

> But shouldn't the drives, network and char devices be qdevs too,
> wouldn't it help the metamachine (or "pc" device)?

We have to clearly separate between host state and guest state.
qdev is about guest state.

A disk has two sides:  The host side (virtual drive foo is a lvm volume 
in raw format / a file in qcow2 format / a iso image / whatever else) 
and the guest side (this virtual drive is a master ide disk / scsi disk 
with id 3 / virtio disk / ...).  Only the later is represented by qdev. 
  The link between the two is a property.

Likewise for chardevs and network.

cheers,
   Gerd