qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device
Date: Wed, 10 Apr 2013 11:40:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

Il 10/04/2013 02:09, li guang ha scritto:
>> > 
>> > Then I explained in my other message why this is wrong.  The API may
>> > well be "bad" (if so, please explain why), but at least it is the right
>> > tool to model this.  QEMU models abstract concepts (memory, timers,
>> > powerdown) with APIs, not with devices.
>> > 
> It's probably not 'bad', just only not native,

The point of having an API, instead of a device, is to do things in a
way that works decently for both "sides" who use it: device models on
one side, monitor and user interface on the other.

> because real hardware does not do thing that way

At some point you have to depart from real hardware, for example in the
case of a disk a virtual machine will write to a file and not to a
magnetic surface.  We try to place APIs at the exact point where this
separation happens.  Are you saying our API is placed wrong?  If so,
where would you put it?

> , and also, this power chip is not purely
> conceptual, it just try to integrate jobs of power control from
> different platform.

That's the job of an API, not a device.

> of course, I can model this power chip as real hardware which exists
> in specific platform.

What power chip do you have in mind, for example, in PCs?  Can you point
to the datasheet?  Would an implementation of that device require
changes to the API?

> can we just feel happy with current implementation and don't want
> to try other things?  :-)
> or do you consider this totally wrong for direction?

Creating an abstract device that does not match real hardware is wrong.
 Improving the API could be more interesting.

Paolo



reply via email to

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