QEMU PEG Meeting - January 22, 2015

Jump to: navigation, search

Attendees: Eric, Christian, Rob, Leon, Matthew, Yongbok

Video: Video of Meeting


Eric does an introduction and welcomes everyone to the meeting. Opens the meeting up to introductions.

Leon introduces self. Mentions he's contributing to PRIP 4 which already has a few users.

Matthew introduces self. Contributing to GCC for MIPS.

Rob introduces self. Has been working internally to IMG on getting the prpl QEMU PEG promoted. Focuses on simulators for MIPS.

Yongbok introduces self. Has been working on PRIP 4.

Christian introduces self. Focuses on MIPS simulators. Currently an observer in QEMU PEG.

Eric setup the mailing list notification for Github changes. Everyone in the meeting has expressed that it's valuable.

Rob not sure if our current method for suggesting changes is good for suggestions and proposed changes. Wonders if a question and answer forum would be better. Email not good for asking questions in all cases and can’t form community around them.

Eric will set up a forum for discussing potential idea.

Eric begins discussion on the mission of the QEMU PEG

Rob says they have no greater goal right now than folks registering their interest in using QEMU in related ways. Right now MIPS is the main related way. Doesn’t want to restrict the focus and discourage folks from getting involved in the PEG. Simulators and emulators aren’t used enough and we should find out why folks don’t use them.

Eric suggests the idea of the PEG being focused on test

Rob expressed that testing is a core part of virtualization in general. The PEG requires a larger user base to verify quality before changes are sent upstream

Matthew thinks that we should make it clear that if someone pushes code to the QEMU PEG that it doesn’t mean it will automatically be upstreamed. Keeping expectations for contributors clear.

Rob agrees. Sees QEMU PEG as a polite backwater of upstream. Even unaccepted pull request allow us to understand what people can’t quite get resolved in QEMU already.

Matthew thinks QEMU PEG is a good place to keep branches for numerous companies in one place. Rob agrees.

Rob suggests that maybe we need to have a way to moving PRIPs forward without any plus votes if enough time has passed.

Matt brings up the idea of the prpl github hosting a copy of the toolchains used in building QEMU. When individuals new features in a piece of the toolchain, they could update it in the prpl Github repositories

Eric asks if folks have any short to long term goals, whether technical or community.

Rob expressed that setting specific goals might prevent other folks from joining. Look at encouraging people to submit to prpl just so others can see what they’ve done even if they can’t take the time to submit to upstream. Also be a place to help those folks become an upstream contributor when they want to.

Matthew wondered if there’s any value in trying to get the Android emulator involved in the prpl QEMU PEG. Rob feels the difference between Android QEMU and upstream is big enough that bring the emulator features in would necessitate prpl QEMU becoming a fork. Rob believe the biggest issue with upstream running Android is the lack of semi-hosted 3d. Question of what do folks want to emulate, everything with pure emulation or use host 3d to speed it up? Very big, requires the focus of a large group. It can be difficult to decide on the boundary of what should be emulated.

Matthew suggested the idea of improving User mode Linux in QEMU which is being partly addressed by PRIP 4

Matthew is trying encourage GNU folks to test their libraries, like glibc in QEMU but doesn’t work correctly now.

Matthew discusses his idea of configurable CPUs to turn on and off features in order to test compilers for all kinds of processors. Particularly useful on MIPS but also ARM and maybe others. QEMU upstream wants real CPUs, not abstract so that would have to be agreed upon by them. Have to balance upstream QEMU’s view of chips versus our needs. Useful for compilers as well as the Linux kernel when they detect features to emulate them as needed.