From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=45677 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OM2We-0000UX-56
	for qemu-devel@nongnu.org; Tue, 08 Jun 2010 13:23:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OM2Wc-0001IZ-ID
	for qemu-devel@nongnu.org; Tue, 08 Jun 2010 13:23:44 -0400
Received: from mail-px0-f173.google.com ([209.85.212.173]:37036)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OM2Wc-0001IE-7n
	for qemu-devel@nongnu.org; Tue, 08 Jun 2010 13:23:42 -0400
Received: by pxi2 with SMTP id 2so1828203pxi.4
	for <qemu-devel@nongnu.org>; Tue, 08 Jun 2010 10:23:38 -0700 (PDT)
Message-ID: <4C0E7C95.9010204@codemonkey.ws>
Date: Tue, 08 Jun 2010 12:23:33 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
References: <1275954730-8196-1-git-send-email-aliguori@us.ibm.com>
	<201006081530.19546.paul@codesourcery.com>
	<4C0E6199.6030706@codemonkey.ws>
	<201006081636.12242.paul@codesourcery.com>
	<4C0E6894.9000901@redhat.com>
In-Reply-To: <4C0E6894.9000901@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15; 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.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: Paolo Bonzini <pbonzini@redhat.com>
Cc: Glauber Costa <glommer@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org


> One "smart way to implement default devices" could be an inclusion 
> mechanism where a machine can ask qemu to read other config files.  
> Then you'd have config files for the default serial/parallel/etc.  
> This could also be implemented on top of choices 2/3/4 though.

Defaults are tough because there are multiple ways to create devices 
today.  Here's something that could potentially address the problem.  
I'll focus on -serial but it's equally applicable to the other default 
devices.

We would introduce serial0, serial1, serial2, serial3 MachineCore 
properties.  These properties would be chardev names.

The pc machine types would do:
    QOPT_VALUE("serial0", "__default_serial0");

In vl.c, we would always create a __default_serial0 chardev of 'vc'.

The -serial option would keep a counter and:

   -serial mon:stdio -serial vc

Would be equivalent to:

  -chardev mon:stdio,id=__serial0 -machine serial0=__serial0 \
  -chardev vc,id=__serial1 -machine serial1=__serial1

-nodefaults simply suppresses the creation of the default serial devices.

It's the job of the MachineCore to try to find each of the serialN 
properties and if the chardevs have been created, use qdev to create an 
appropriate serial port device.

This would apply equally well to parallel and virtcon.

Networking is a bit of a nightmare as many boards simply ignore the 
networking options.  Floppy and cdrom can work in this way too.

Regards,

Anthony Liguori

> Paolo