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.mayd...@linaro.org> wrote: > 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 >
