-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 11.02.2012 15:24, schrieb Jan Kiszka: > 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. I already answered that above. Please join #qemu if you further want to discuss that, for this thread seems to lead nowhere. Andreas > >> 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 > - -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBAgAGBQJPNoALAAoJEPou0S0+fgE/OHAQALK7X6v9nA0A4tZ8umD4Ak8p DkyHX9N0pkv8Jc9y06WWLCzsgCQJFxPKp0n0mpWHhG96mWryez+Cd8x00W9wJJWx A15beRV80jwpDWlkNMtnQ+T9kvVamUsL3a090Bgcb662EkCpfR5UtjDlrYBM7X7f C/ejV31NYnFIXM5F2TcsURrXZ7GRXNeSRsoXrt2WoCBhFkf+DBek8ejEsYcFS6q0 lrqoggHTVKRZuGbBIJ9yS3/L/pf6gWDOv1ZyUAHfAUeWt2rD3NxNFHHFLbrl3d47 k5Yev4acZOTe6ozgvK3qWcrvA2t42BmKTCA7FqLKg2057szll277wKHf0K2xqlvs oYTbSk4t9IWI4StBFevgVDM0kaXg6OAGKiDDP8PRrBI3YzJajLL6zkDVitA5Hp0N LPryOYwhI+KtO3Too7R919UDZIoZ+pg2Mm+L1/1IuneB8Ar1MeiPwU0zXLYGiDVx ZrMzjhhbYJn+PPC8FxI9gnaPkLVkZzSfcXkpA1RXLZdpkjdmt4rwA0KfFNB000DU fag3rAGTdcvT8O58K2FXYAWe8VFqA979VHWxsTOLrVX3rL9Xbi63SUfvz/joMryO mZMYsJ/NGHd5IVYdWP0kBdxuXRtFUaqHnp7PFnwj0IXtnV13csgB2nN+HN5wJULs A855i5ibqUahcKGej48W =jxwX -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
