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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
