Re: Replace calls to functions named cpu_physical_memory_* with address_space_*.

[Tanmay <tanmaynpatil105@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

Yeah, I felt that it may not be a cakewalk as it might sound.

You're right, trying to understand the whole code is overwhelming. I'll
start with a small section instead.

I have interest in working on x86_64 and Aarch64 architectures within qemu.
Please let me know if there are any specific tasks from where I can start
exploring.

Thanks,
Tanmay

On Thu, 26 Oct 2023 at 22:16, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Thu, 26 Oct 2023 at 13:48, Tanmay <tanmaynpatil105@gmail.com> wrote:
> > I'm really interested in contributing to qemu. I wanted to
> > work on the renaming API calls cpu_physical_memory_* to
> > address_space_*. I couldn't find any related issues on the
> > GItlab tracker. Can I work on this issue?
>
> You're welcome to, but be aware that this is unfortunately
> one of the items in the "BiteSizedTasks" list that is
> not as simple as the one-line description makes it sound.
> (I have a personal project to try to go through that page and
> either expand entries into issues in gitlab that describe the
> task in more detail, or else delete them if they don't really
> seem to be "bite sized". But I haven't got very far with it yet,
> so there are still quite a few unhelpful "landmine" tasks on it.
> Sorry about that :-(  )
>
> It also is something where the right thing to do is going to
> depend on the call-site and what that particular device or piece
> of code is trying to do -- it is not a mechanical conversion.
> (This is partly why the conversion is not yet complete.)
>
> Most of the devices which use these functions should indeed
> use address_space_* functions instead, but the question then
> is "what address space should they access?". That usually ought
> to be one passed into them by the board code. (commit 112a829f8f0a
> is an example of that kind of conversion.) Unfortunately many
> of the remaining uses of cpu_physical_memory_* in hw/ are
> in very old code which hasn't even been converted to the
> kind of new device model coding style that would allow you to
> provide an address space by a QOM property that way. So for
> those devices this would be just one of a whole pile of
> "modernizations" and refactorings that need to be done.
>
> I think what I would suggest is that rather than starting
> with this task in general, that you start with what part
> of QEMU you're interested in working on in particular (eg
> whether you're interested in a particular target architecture
> or a particular subsystem like migration, etc), and then
> we can probably find some tasks that relate to that specific
> interest and help in starting to understand that part of the
> code. (QEMU as a whole is too big for anybody to understand
> all of it...) If what you want to work on turns out to
> involve one of the bits of code which needs this API upgrade,
> maybe we can help you work on that; but it might turn out that
> the two don't overlap at all, or that there's a better starting
> task.
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 3671 bytes --]