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