On Thu, 26 Oct 2023 at 13:48, Tanmay <tanmaynpatil...@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
