> >> AFAICS the current commandline options only result in simple addition of
> >> devices. They might add slightly different devices in slightly different
> >> places, but that's easy to accommodate by having the machine define a
> >> few standard device/bus IDs.
> >>
> >> IMO it's even more lame
On Wed, Jun 9, 2010 at 8:52 PM, Anthony Liguori wrote:
> On 06/09/2010 03:47 PM, Blue Swirl wrote:
>>
>> On Wed, Jun 9, 2010 at 2:30 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 empt
On 06/09/2010 03:47 PM, Blue Swirl wrote:
On Wed, Jun 9, 2010 at 2:30 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 thi
On Wed, Jun 9, 2010 at 2:30 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 p
> >> 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 vi
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
> >>>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-specifie
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 conf
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 ma
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
> > 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.
>
On 06/08/2010 10:58 AM, Paolo Bonzini wrote:
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
s
On 06/08/2010 09:30 AM, Paul Brook wrote:
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
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 a
> 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
>
> > 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 m
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
trivially
17 matches
Mail list logo
