On 2012-02-11 14:21, Andreas Färber wrote: > Am 11.02.2012 14:07, schrieb Jan Kiszka: >> On 2012-02-11 14:06, Andreas Färber wrote: >>> Am 11.02.2012 13:43, schrieb Jan Kiszka: >>>> On 2012-02-11 12:49, Andreas Färber wrote: >>>>> Am 11.02.2012 12:25, schrieb Blue Swirl: >>>>>> I think using cpu_single_env is an indication of a >>>>>> problem, like poor code, layering violation or poor API >>>>>> (vmport). What is your use case? >>>>> >>>>> I couldn't spot any in this series. Jan, note that any new >>>>> use of env or cpu_single_env will need to be redone when we >>>>> convert to QOM CPU. >>> >>>> cpu_single_env should have nothing to do with QOM. >>> >>> It does, cf. my patch series: Current CPU*State is being embedded >>> in the QOM object and most future code outside TCG will use a > > Let me stress this: > >>> CPU rather than CPUState pointer. > >>> The reason is that CPUState is totally target-specific and does >>> not belong in common code. > >> So are the devices that depend on a current CPU pointer. You will >> have to provide something equivalent. > > 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. Do you plan accessors for registers? And a service to return the CPU object associated with the execution context? Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
