qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support


From: Paul Brook
Subject: Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
Date: Wed, 9 Jun 2010 03:11:41 +0100
User-agent: KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.3; x86_64; ; )

> >>>    Once you eliminate machine_register_core that knowledge has
> >>> 
> >>> somehow got to come from your device tree description file.  Having a
> >>> single device tree that can morph into significantly different machines
> >>> seems like unnecessary complexity given this is a user-specified file.
> >> 
> >> 99% of qemu users will never touch a device tree.  The practical matter
> >> is, we're going to have to provide higher level interfaces that allow a
> >> user to significantly morph a base device tree into something different.
> > 
> > That's the bit I don't get.  Why are we significantly morphing a base
> > device tree?  Surely it's easier to just use a different base tree.
> 
> Because at some point the base tree will have to be written in C.

No. You can start with a completely empty machine.
We don't/shouldn't need any machine specific C code.
When I submitted the original qdev code I also posted a proof-of-concept patch 
that built the whole machine based on a config file with no hardcoded 
knowledge of the machine structure.

> Of course you have to decide where to stop allowing customization, but
> anyway it will be significantly more complex than a QemuOpts config
> file.  QemuOpts obviously doesn't have the flexibility to create an
> entire device tree.

Why not?
The current -device option already provides the majority of the functionality 
required.  Most of the missing bits are incomplete qdev conversion.
I'm not saying that creating a whole machine via -device options is an elegant 
solution (hence the interest in things like FDT) but in I see no reason why it 
shouldn't work.

IMO all uses of the no_user flag are bugs resulting from incomplete/incorrect 
qdev conversions.
 
> Want to let the user add an IDE controller?  Fine, you need to provide
> him with a way of writing the following logic:
> 
>      for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
>          hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
>      }
>      pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
> 
> What do you do?

-device piix3-ide. See also docs/qdev-device-use.txt

Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]