GSoC/Ideas - Revision history

Nicolas Dechesne: /* remote debugging with devtool */

2021-06-02T23:42:51Z

remote debugging with devtool

← Older revision		Revision as of 23:42, 2 June 2021
Line 25:		Line 25:

	*; Where to Ask Questions		*; Where to Ask Questions
	*: #yocto on irc.~~freenode~~.~~net~~ or the [https://lists.yoctoproject.org/g/yocto yocto mailing list]		*: #yocto on irc.libera.chat or the [https://lists.yoctoproject.org/g/yocto yocto mailing list]

	*; Potential Mentor		*; Potential Mentor
	*: [[User:Trevor Woerner]] (tlwoerner on irc (~~freenode~~ and OFTC))		*: [[User:Trevor Woerner]] (tlwoerner on irc (Libera.chat and OFTC))

	*; Description		*; Description

Rpurdie at 11:23, 21 February 2020

2020-02-21T11:23:07Z

@@ Line 50: / Line 50: @@
 *; Description
 *: There are many areas where a 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.
 ----

Rpurdie: /* build improvements */

2020-02-11T21:38:19Z

build improvements

← Older revision		Revision as of 21:38, 11 February 2020
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 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.		*: There are many areas where a 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.
	----		----

Rpurdie: /* build improvements */

2020-02-11T21:37:27Z

build improvements

← Older revision		Revision as of 21:37, 11 February 2020
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 ~~and entire build~~ then look for ways to provably improve the build speed and/or resources used in measurable ways.		*: 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.
	----		----

Trevor Woerner: add RP's idea for build improvements

2020-02-11T21:00:06Z

add RP's idea for build improvements

@@ Line 32: / Line 32: @@
 *; 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.
 ----

Trevor Woerner: /* remote debugging with devtool */

2020-02-05T01:02:37Z

remote debugging with devtool

← Older revision		Revision as of 01:02, 5 February 2020
Line 31:		Line 31:

	*; Description		*; 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.		*: 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.
	----		----

Trevor Woerner at 00:55, 5 February 2020

2020-02-05T00:55:23Z

← Older revision		Revision as of 00:55, 5 February 2020
Line 6:		Line 6:

	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.		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 [https://bugzilla.yoctoproject.org Yocto Project Bugzilla]. A number of bugs have been assigned to [https://bugzilla.yoctoproject.org/buglist.cgi?emailtype2=substring&list_id=616486&resolution=---&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO&email2=newcomer%40yoctoproject.org&emailassigned_to2=1 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 [https://bugzilla.yoctoproject.org/buglist.cgi?list_id=616487&bug_severity=enhancement&resolution=---&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO 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!		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!

Trevor Woerner at 00:35, 5 February 2020

2020-02-05T00:35:46Z

← Older revision		Revision as of 00:35, 5 February 2020
Line 1:		Line 1:
	= Project Ideas for the Yocto Project Google Summer of Code =		= 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.

			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 ===		=== Miscellaneous Ideas ===
Line 18:		Line 26:

	*; Potential Mentor		*; Potential Mentor
	*: Trevor Woerner (tlwoerner on irc (freenode and OFTC))		*: [[User:Trevor Woerner]] (tlwoerner on irc (freenode and OFTC))

	*; Description		*; 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		*: 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.
	----		----

Trevor Woerner at 00:14, 5 February 2020

2020-02-05T00:14:34Z

← Older revision		Revision as of 00:14, 5 February 2020
Line 1:		Line 1:
	= Project Ideas for the Yocto Project Google Summer of Code =		= Project Ideas for the Yocto Project Google Summer of Code =

			=== Miscellaneous Ideas ===

	==== remote debugging with ''devtool'' ====		==== remote debugging with ''devtool'' ====

Trevor Woerner: Created page with "= Project Ideas for the Yocto Project Google Summer of Code = ==== remote debugging with ''devtool'' ==== ; Difficulty : medium ; Skills Required : python 3 *; Hardwar..."

2020-02-05T00:12:40Z

Created page with "= Project Ideas for the Yocto Project Google Summer of Code = ==== remote debugging with ''devtool'' ==== *; Difficulty *: medium *; Skills Required *: python 3 *; Hardwar..."

New page

= Project Ideas for the Yocto Project Google Summer of Code =

==== 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 [https://lists.yoctoproject.org/g/yocto yocto mailing list]

*; Potential Mentor
*: 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
----

GSoC/Ideas - Revision history

Nicolas Dechesne: /* remote debugging with devtool */

Rpurdie at 11:23, 21 February 2020

Rpurdie: /* build improvements */

Rpurdie: /* build improvements */

Trevor Woerner: add RP's idea for build improvements

Trevor Woerner: /* remote debugging with devtool */

Trevor Woerner at 00:55, 5 February 2020

Trevor Woerner at 00:35, 5 February 2020

Trevor Woerner at 00:14, 5 February 2020

Trevor Woerner: Created page with "= Project Ideas for the Yocto Project Google Summer of Code = ==== remote debugging with ''devtool'' ==== *; Difficulty *: medium *; Skills Required *: python 3 *; Hardwar..."

Trevor Woerner: Created page with "= Project Ideas for the Yocto Project Google Summer of Code = ==== remote debugging with ''devtool'' ==== ; Difficulty : medium ; Skills Required : python 3 *; Hardwar..."