Hi Anastasia, Am 03.02.22 um 04:55 schrieb Anastasia Klimchuk: > Thomas, Simon, > > Thank you so much!! We will be updating project ideas document at the > end of this week (or maybe beginning next week), so I will add names > there. > > And I want to confirm on this thread that I also will be a Mentor > myself. My preference is the effort that I started "Emulate hardware > and filesystem in platform-independent way for unit tests", however I > think I can do some other projects as well, especially with co-mentor > and other people helping.
I'm glad that there is an effort to participate in GSoC again and I hope it will be successful. Reading through the current GSoC ideas list, I would like to share a few thoughts. Unfortunately, some of these ideas are missing a bit of context or may cause needless code churn. Missing context: - Design and implement new CLI based on libflashrom and extend the API as necessary. That would be the fourth or fifth user interface for flashrom. Now if you mean cli_classic.c should be rewritten to use libflashrom, that's something different. The idea doesn't specify more details, but please note that any CLI will have to be supported for the next 20 years and subsequent generations of developers may not be willing to do that. - Emulate hardware and filesystem in platform-independent way for unit tests. flashrom has builtin code for hardware emulation. Some more hardware is emulated quite well by qemu. There were various patches for qemu floating around to help testing flashrom hardware drivers, but someone (TM) would have to dig through our mailing list as well as others. Some more guidance for students is definitely necessary. Code churn: - Refactor arguments parser. The rationale given is "Strings are complicated in C to work with. However, the idea of this is to deduplicate a lot of code.". I agree that strings in C need careful programming. That's also a reason why I doubt rewriting the code would be a good idea. This idea in particular seems to suggest that reinventing a full-blown argument parser building bespoke structures is a way to reduce complexity. In the past, we had proposals to store configuration data and even command line arguments in JSON or XML, then use a system library to parse it. The reasoning for the XML/JSON was that building your own parser was a bad idea. Someone else will come along and refactor things again if we merge a bespoke parser now. "Hey, thanks for your contribution, it will be replaced in the next GSoC" is not something we would want to advertise. I do acknowledge that flashrom has gotten lots of refactoring, but I'm a bit afraid the changelogs suggest that in many cases "TEST=builds" seems to have been the only test that was performed. It's a good thing to have unit tests, but tests on real hardware should be performed if a driver has been refactored. After all, people rely on flashrom to not break their hardware. Regards, Carl-Daniel _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
