On 06/08/2010 09:11 PM, Paul Brook wrote:
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.
I think you're missing the argument. I should be possible to create a
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.
I think you're missing the argument. I should be possible to create a
machine entirely from a FDT or via -device
On Wed, Jun 9, 2010 at 2:30 PM, Paul Brook p...@codesourcery.com wrote:
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.
I think you're missing the argument. I should
On 06/09/2010 03:47 PM, Blue Swirl wrote:
On Wed, Jun 9, 2010 at 2:30 PM, Paul Brookp...@codesourcery.com wrote:
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
On Wed, Jun 9, 2010 at 8:52 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 06/09/2010 03:47 PM, Blue Swirl wrote:
On Wed, Jun 9, 2010 at 2:30 PM, Paul Brookp...@codesourcery.com wrote:
Because at some point the base tree will have to be written in C.
No. You can start with a
On 06/08/2010 05:12 AM, Paul Brook wrote:
This series introduces a rather radical change in the way we deal with
machine definitions in QEMU.
I think we should aim to eliminate machine_register_core, and design
appropriately. In particular I'd try and avoid adding options that become
I'm undecided how much parameterisation it's worth trying to support in
the device tree. IMO the current code has way too much magic, because
creating a new variant involves hacking and rebuilding pc.c.
See patch 22/22. There is really no magic involved, even though the
compat machines
The magic I'm preferring to is precisely things like pci=on.
Hmm, pci=on is magic indeed. :-)
What I'm objecting to is making machine construction be controlled by an
arbitrary set of hardcoded parameters.
My argument is that in the short term this parameterization provides limited
On 06/08/2010 05:36 PM, Paul Brook wrote:
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
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
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
On 06/08/2010 04:05 PM, Alexander Graf wrote:
On 08.06.2010, at 18:15, Anthony Liguori wrote:
4) expose everything to the user, at the cost of regretting it later. This is
the current patchset.
One smart way to implement default devices could be an inclusion mechanism
where a
On 08.06.2010, at 18:15, Anthony Liguori wrote:
4) expose everything to the user, at the cost of regretting it later. This
is the current patchset.
One smart way to implement default devices could be an inclusion mechanism
where a machine can ask qemu to read other config files.
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
14 matches
Mail list logo
