Marc Jones wrote:
Mentoring isn't hard work, but it does take attention every week
..
The lack of interest is is a bit ironic
Please don't confuse lack of time for lack of interest.
I am sure that quite a lot of people in the coreboot community are interested in participating in GSoC, but I think it is clear to everyone that in order to do so we would have to bring significantly more to the table, and I guess that there simply isn't time for that.
we have had more contributions to coreboot than ever before.
While that *is* true, the community landscape has also changed quite drastically over the last few years. There are only very few code contributors for the majority of the code. Economy of scale is clearly in play, meaning much less margin all around.
Honestly, I'm disappointed that we can't identify good projects and guidance for new firmware developers.
Most everyone is too busy even to rework their own code, and coreboot.git is merely a public repository with a bit of shared infrastructure.
There is next to no interaction in the community, so I'm not at all surprised that we fail to identify projects and processes. When it doesn't even work for the community, how could it work for us bringing another community (students) into ours?
Without good complete project ideas, applying for GSoC is pointless.
Certainly agreed.
Please put forward coreboot, flashrom, and payload ideas.
None of the modern platform development in coreboot happens in the open, so anything related to that is basically not doable.
The only doable coreboot project I can think of is to implement AGESA for a new mainboard. It took Rudolf a few months to climb the AGESA learning curve, and at the moment I believe he is the only community member outside of AMD who has done that.
Doing an AGESA port would be quite educational for a student, but obviously also immensely challenging, because unlike Rudolf the student probably does not have years of experience with PC firmware.
A good student would continue to intelligently drive discussion about how to integrate AGESA and coreboot better, while also keeping an eye toward keeping AGESA code as pristine as possible in order to facilitate inclusion of possible later code drops from AMD. (This is part of the "Move configuration to Kconfig" Infrastructure Project.)
I don't expect qualified applicants. I would love to be proven wrong.
Other than that, there are various uninspiring infrastructure projects: http://www.coreboot.org/Infrastructure_Projects
Payloads - a way to provide UEFI with Secure Boot support is the only thing that mainstream industry has any interest in, since that's what Microsoft requires for certification. David and Patrick were already working on that, so there's not much for a student project to do..
Other payload ideas include a solution for chaining payloads, so that coreboot starts one payload, but that payload can in turn start one other payload after it has finished. This would be a simple libpayload project. The code for this is already available in SeaBIOS. A good use case would be for the nvramtool-like utility that Patrick wrote, allowing a boot-time menu or in fact a more complex sequence of payloads to be configured into coreboot Kconfig and maybe built all at once while building coreboot - similar to how SeaBIOS gets built.
//Peter
On Mon, Mar 18, 2013 at 7:07 PM, Peter Stuge peter@stuge.se wrote:
Marc Jones wrote:
Mentoring isn't hard work, but it does take attention every week
..
The lack of interest is is a bit ironic
Please don't confuse lack of time for lack of interest.
I am sure that quite a lot of people in the coreboot community are interested in participating in GSoC, but I think it is clear to everyone that in order to do so we would have to bring significantly more to the table, and I guess that there simply isn't time for that.
we have had more contributions to coreboot than ever before.
While that *is* true, the community landscape has also changed quite drastically over the last few years. There are only very few code contributors for the majority of the code. Economy of scale is clearly in play, meaning much less margin all around.
Honestly, I'm disappointed that we can't identify good projects and guidance for new firmware developers.
Most everyone is too busy even to rework their own code, and coreboot.git is merely a public repository with a bit of shared infrastructure.
There is next to no interaction in the community, so I'm not at all surprised that we fail to identify projects and processes. When it doesn't even work for the community, how could it work for us bringing another community (students) into ours?
i would like to see increased interaction. In some ways gerrit has helped in code reviews, but it has hindered general development discussion.
Without good complete project ideas, applying for GSoC is pointless.
Certainly agreed.
Please put forward coreboot, flashrom, and payload ideas.
None of the modern platform development in coreboot happens in the open, so anything related to that is basically not doable.
The only doable coreboot project I can think of is to implement AGESA for a new mainboard. It took Rudolf a few months to climb the AGESA learning curve, and at the moment I believe he is the only community member outside of AMD who has done that.
Doing an AGESA port would be quite educational for a student, but obviously also immensely challenging, because unlike Rudolf the student probably does not have years of experience with PC firmware.
True, but given a good mentor and working on it everyday should be very do-able. Especially with a well selected student and target.
A good student would continue to intelligently drive discussion about how to integrate AGESA and coreboot better, while also keeping an eye toward keeping AGESA code as pristine as possible in order to facilitate inclusion of possible later code drops from AMD. (This is part of the "Move configuration to Kconfig" Infrastructure Project.)
I don't expect qualified applicants. I would love to be proven wrong.
Firmware development is certainly some of the toughest to get started with and it is even more difficult in x86. This has been a hurdle even for veterans.
Other than that, there are various uninspiring infrastructure projects: http://www.coreboot.org/Infrastructure_Projects
Payloads - a way to provide UEFI with Secure Boot support is the only thing that mainstream industry has any interest in, since that's what Microsoft requires for certification. David and Patrick were already working on that, so there's not much for a student project to do..
I think that there is probably a lot to do for a UEFI payload, but I don't know. Patrick or Stefan would know better.
Other payload ideas include a solution for chaining payloads, so that coreboot starts one payload, but that payload can in turn start one other payload after it has finished. This would be a simple libpayload project. The code for this is already available in SeaBIOS. A good use case would be for the nvramtool-like utility that Patrick wrote, allowing a boot-time menu or in fact a more complex sequence of payloads to be configured into coreboot Kconfig and maybe built all at once while building coreboot - similar to how SeaBIOS gets built.
I think that these are some really good ideas. Would you like to put them on the wiki page and start flushing them out? I think that it is payload and infrastructure projects where most students would be capable of finishing in a summer project. I don't know if we will get student interest in that type of project.
it is hard to find people that are passionate about firmware, but I would like to try to be positive and promote the advances that we have made in the last few years.
Thanks for your thoughtful response.
Marc