Re: [Qemu-devel] KVM call minutes for Feb 8

From: Gleb Natapov <gleb@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Chris Wright <chrisw@redhat.com>,
	kvm@vger.kernel.org, Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] KVM call minutes for Feb 8
Date: Thu, 10 Feb 2011 16:20:44 +0200	[thread overview]
Message-ID: <20110210142044.GD24525@redhat.com> (raw)
In-Reply-To: <4D53F06C.9090500@codemonkey.ws>

On Thu, Feb 10, 2011 at 03:04:28PM +0100, Anthony Liguori wrote:
> On 02/10/2011 02:27 PM, Gleb Natapov wrote:
> >I don't care how command line will look like, but I do not see how you
> >will support ide=off without device composition unless you put ad-hoc
> >ifs all over your i440fx device code.
> 
> Yes, in the piix3 device code, the ide property would trigger an if().
> 
> BTW, I'm extremely sceptical that you really do have machines w/o
> IDE at all.  Even the servers we ship with only SAS or SCSI support
> still have an integrated IDE controller.
> 
> Since most servers are built from the same chipset design that has
> IDE, I don't really see how you could build a modern system without
> IDE.
> 
Well, this may be true. But since I can't find IDE (or ATA) nor in lspci
neither in dmesg does it really matter that silicon that implement IDE
functionality is present somewhere inside the box?

> >>And that's okay, but the base modelling ought to follow rea
> >>hardware closely with deviations being the exception.
> >>
> >You keep saying this without explaining why. But with device composition
> >you will have exactly that, you will compose real chipsets using config
> >files, not code.
> 
> Yeah, that's been the direction we've been going in since qdev was
> introduced.  I'm now convinced that this is overly ambitious.  By
> simply reducing the scope of conversion, we get 99% of the benefit
> with 10% of the effort.  Seems like a no brainer to me.
> 
Jugging by how well all previous conversion went we will end up with one
more way of creating devices. One legacy, another qdev and your new one.
And what is the problem with qdev again (not that I am a big qdev fan)?
The fact that there is no enough interest to convert all devices to it?
How new way of doing things will solve this?

Just to be clear I do not have problem with not having ability to
compose x86 without pit or kbd controller. Basic things like RTC, pit,
pic, ioapic, dma, kbd should be created unconditionally as part of x86
pc machine. But IMHO you are trying to take things to other extreme.

--
			Gleb.