GSoC/Ideas: Difference between revisions
(add RP's idea for build improvements) |
|||
Line 49: | Line 49: | ||
*; Description | *; Description | ||
*: There are many areas where an build can be improved in terms of memory consumption, recipe/config parsing, etc. For this project the student would be expected to instrument and profile | *: There are many areas where an build can be improved in terms of memory consumption, recipe/config parsing, etc. For this project the student would be expected to instrument and profile either builds or some key section/stage of builds then look for ways to provably improve the build speed and/or resources used in measurable ways. Specific examples a) A key recent development is multiconfig but currently this causes significant parsing speed and memory overhead b) general parsing speed, particularly when adding many layers is a concern for many users c) memory overhead of bitbake often seems high, can it be quanitifed and reduced, particularly for parallel parsing?. Additionally it is worth noting the bitbake -P profiling option already exists and may assist. | ||
---- | ---- |
Revision as of 21:37, 11 February 2020
Project Ideas for the Yocto Project Google Summer of Code
In General
What follows, in the #Miscellaneous Ideas section, are suggested projects by various members of the community. This page welcomes ideas from the community. Please add your ideas! Don't worry too much about the mentoring aspect; if you have a good idea put it here even if you are unavailable to mentor, perhaps someone else in the community will be able to act as a mentor for your idea. If you don't have an account to edit this page, please send any interesting ideas to User:Trevor Woerner by email (if you're in this community, you'll know how to email me).
If you are a student, this page is meant to help get you thinking about potential ideas for GSoC. A student is welcome to propose their own project ideas that aren't necessarily on this list.
One awesome place to look for project ideas is the Yocto Project Bugzilla. A number of bugs have been assigned to newcomer@yoctoproject.org. Many of these "newcomer" bugs would be too simple to comprise a GSoC project, but they could act as an inspiration for a more worthy project. Another excellent way to look for GSoC-worthy projects is to query the bugzilla looking for enhancement bugs; many of these enhancements could make for a great GSoC project!
In all cases, the student is responsible for finding a suitable mentor. Just because someone says they could be a potential mentor doesn't obligate them to mentor. Mentoring is an unpaid, volunteer position, if someone does agree to mentor it is because they are taking time away from their other obligations to do so!
Miscellaneous Ideas
remote debugging with devtool
- Difficulty
- medium
- Skills Required
- python 3
- Hardware Required
- no hardware is required, this can all be done with qemu
- Where to Ask Questions
- #yocto on irc.freenode.net or the yocto mailing list
- Potential Mentor
- User:Trevor Woerner (tlwoerner on irc (freenode and OFTC))
- Description
- A build generates all the pieces required to perform remote debugging (via cross-gdb) but getting everything to work requires a lot of manual fiddling (involving an SDK). devtool should be able to make this easier, and would also include the coding (devtool modify), cross-building (devtool build), and upload (devtool deploy-target) pieces to complete the remote debugging loop. Ideally remote debugging with a JTAG via openocd should also be supported too.
build improvements
- Difficulty
- medium-hard
- Skills Required
- python3, bitbake, building software, build systems
- Hardware Required
- no hardware is required
- Where to Ask Questions
- #yocto on irc.freenode.net or the yocto mailing list
- Description
- There are many areas where an build can be improved in terms of memory consumption, recipe/config parsing, etc. For this project the student would be expected to instrument and profile either builds or some key section/stage of builds then look for ways to provably improve the build speed and/or resources used in measurable ways. Specific examples a) A key recent development is multiconfig but currently this causes significant parsing speed and memory overhead b) general parsing speed, particularly when adding many layers is a concern for many users c) memory overhead of bitbake often seems high, can it be quanitifed and reduced, particularly for parallel parsing?. Additionally it is worth noting the bitbake -P profiling option already exists and may assist.