[Top][All Lists]
[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
- Re: [Qemu-devel] [PATCH 0/22] Refactor machine support, (continued)
- Re: [Qemu-devel] [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/07
- [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paolo Bonzini, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paolo Bonzini, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Alexander Graf, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support,
Paul Brook <=
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Blue Swirl, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Blue Swirl, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/09
Re: [Qemu-devel] [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08