Am 10.04.2013 02:09, schrieb li guang: > 在 2013-04-09二的 13:06 +0200，Paolo Bonzini写道： >> Il 09/04/2013 10:26, li guang ha scritto: >>>> qemu_system_suspend_request, qemu_register_suspend_notifier >>>> for S0->S3 >>>> >>>> qemu_system_wakeup_request, qemu_register_wakeup_notifier >>>> for S3->S0 >>>> >>>> qemu_system_powerdown_request, qemu_register_powerdown_notifier >>>> for Sx->S5 >>>> >>>> and the reset mechanism for S5->S0. >>> >>> Yep, I'm trying to supersede these functions >>> by my power chip emulation. >> >> 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, because real hardware > does not do thing that way, and also, this power chip is not purely > conceptual, it just try to integrate jobs of power control from > different platform. > of course, I can model this power chip as real hardware which exists > in specific platform.
Li Guang, I think your problem is a conceptual one: QEMU does not do a system simulation, it does a system emulation. Thus if a chip is hidden from software and not directly accessed in terms of registers from guest software, then we don't model it as a device but call some API functions from where it is supposed to show effects (keyboard controller device MemoryRegionOps, TCG instruction, monitor command, ...). Thus we are reluctant to accept a QOM Device that is neither exposed to the guest nor uses any QOM concepts like inheritance AFAICS. Especially when the advantage of doing so is not well explained. Andreas > 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? -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
