qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 5/7] hw/core/sysbus: add fdt_add_node method


From: Eric Auger
Subject: Re: [Qemu-devel] [PATCH 5/7] hw/core/sysbus: add fdt_add_node method
Date: Thu, 24 Jul 2014 09:36:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 07/24/2014 01:02 AM, Alexander Graf wrote:
> 
> On 23.07.14 17:33, Eric Auger wrote:
>> On 07/08/2014 03:52 PM, Alexander Graf wrote:
>>> On 07.07.14 09:08, Eric Auger wrote:
>>>> This method is meant to be called on sysbus device dynamic
>>>> instantiation (-device option). Devices that support this
>>>> kind of instantiation must implement this method.
>>>>
>>>> Signed-off-by: Eric Auger <address@hidden>
>>> For the reason I stated earlier, I don't think it's a good idea to put
>>> device tree code into our device models.
>> Hi Alex,
>>
>> I would propose we discuss that topic during next KVM call if you are
>> available.
> 
> I lost track when that would be. Next week would work fine, the week
> after not :).

Hi Alex,

Unfortunately I think the last one was this week. If you are available
next week I would propose to setup a short call next week. Who are the
required people in the call aside us and Peter?

> 
>> Hope Peter will be available to join too. Because I feel
>> stuck between not putting things in the machine file (1) - obviously we
>> could put them in a helper module (2) - and not putting them in the
>> device (3).
>>
>> Whatever the solution I fear we are going to pollute something: Any time
>> a new device wants to support dynamic instantiation, we would need to
>> modify the machine file or the helper module with 1 and 2 resp. In case
>> we put it in the device we pollute this latter...
>>
>> My hope was that quite few QEMU platform devices would need to support
>> that feature and hence would need to implement this dt node generation
>> method. To me dynamic instantiation of platform device was not the
>> mainstream solution.
> 
> Quite frankly I don't think it'd be that many. I think we'll cover 99.9%
> of all use cases if we just enable it for the virt machines of e500 and
> arm.
> 
>> Then there is the fundamental question of technical feasibility of
>> devising a generic PlatformParams that match all the specialization
>> needs? Here I miss experience. In case we know the machine type and a
>> small set of additional fields couldn't we do the adaptations you talked
>> about, related to IRQs?
> 
> The problem is that I don't know all the boards and different things
> people come up with either. There's also no reason machine files have to
> stick to the "platform bus" model - they could just take those devices
> and stick them into an existing other virtual bus.
> 
> I don't feel comfortable generalizing something where I'm pretty sure
> things will blow up sooner or later.
ok

Best Regards

Eric
> 
> 
> Alex
> 




reply via email to

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