Yes, you're right. The motivation is I want to implement a device called EC which is a notion from laptop for QEMU, EC has some main functions, like keyboard, mouse, low-speed device control(I2C), special ACPI space, i8042 and ps2 mouse has been done, power control was left, so I tried to add this. so, Andreas, do you know this chip for laptop? any suggestions for this? Thanks!
2013/4/10 Andreas Färber <afaer...@suse.de> > 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 > > -- * Sidere mens eadem mutato*
