On 2012-02-11 15:12, Andreas Färber wrote: > Am 11.02.2012 15:02, schrieb Jan Kiszka: >> On 2012-02-11 14:59, Andreas Färber wrote: >>> Am 11.02.2012 14:35, schrieb Jan Kiszka: >>>> On 2012-02-11 14:21, Andreas Färber wrote: >>>>> CPU base class v3: http://patchwork.ozlabs.org/patch/139284/ >>>>> (v4 coming up) >>>>> >>>>> That doesn't prevent target-specific devices. Although Paolo >>>>> does want that to change wrt properties. >>> >>>> This patch doesn't explain yet what shall happen to >>>> cpu_single_env and CPUState accesses from target-specific >>>> devices. >>> >>> True. We can't change them before all targets are converted. So >>> far I have 3/14 and still some review comments to work in. >>> >>> Another patch in that series uses a macro >>> s/ENV_GET_OBJECT/ENV_GET_CPU/ to go from CPUState -> CPU while >>> we convert targets. >>> >>> Depending on our taste, cpu_single_env might become >>> cpu_single_cpu, single_cpu or cpu_single. >>> >>>> Do you plan accessors for registers? >>> >>> No, registers are in target-specific ARMCPU, S390CPU, MIPSCPU, >>> etc. and their CPU*State. It would be possible to have static >>> inline accessors but so far I've seen no need. > >> Then the devices need to have access to a CPUState pointer, just as >> so far. > > Yes and no. They can have any target-specific pointer they want, just > as before. But no global first_cpu / cpu_single_env pointer - that's If you want to drop first_cpu, you need to provide a for_each_cpu iterating service instead. And cpu_single_env can only be obsoleted if I/O access handlers can otherwise query the triggering CPU. > replaced by CPU pointers, through which members of derived classes can > be accessed (which did not work for CPUState due to CPU_COMMON members > being at target-specific offset in the middle). > > There's nothing wrong with your patch per se, just that it may need to > get refactored some time soonish. We need to be aware of it so that we > don't create merge conflicts for Anthony. There can't be logical merge conflicts as the no fundamentally new requirements are introduced with this series. And we have no code proposal seen yet to address them already for the existing use cases. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
