Development Guidelines: Difference between revisions
Uwe@flashrom.org/ (talk) ("Uwe@flashrom.org/: Created page with '== Patch submission == The following guidelines are for coreboot, but most of them apply to flashrom as well: [http://www.coreboot.org/Development_Guidelines coreboot developmen…'") |
Uwe@flashrom.org/ (talk) ("Uwe@flashrom.org/: *Empty MediaWiki Message*") |
||
| Line 1: | Line 1: | ||
== Patch submission == | == Patch submission == | ||
The following guidelines are for coreboot, but most of them apply to flashrom as well: [http://www.coreboot.org/Development_Guidelines coreboot development guidelines]. | The following guidelines are for [http://www.coreboot.org/ coreboot], but most of them apply to flashrom as well: [http://www.coreboot.org/Development_Guidelines coreboot development guidelines]. The really important part is about the [http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure Signed-off-by procedure]. | ||
The really important part is about the Signed-off-by procedure. | |||
We try to reuse as much code as possible and create new files only if absolutely needed, so if you find a function somewhere in the tree which already does what you want (even if it is for a totally different chip), please use it. Most chips work fine with probe_jedec even if the command sequence seems to differ at first glance. See also [[#Command_set_secrets|Command set secrets]] | We try to '''reuse as much code as possible''' and create new files only if absolutely needed, so if you find a function somewhere in the tree which already does what you want (even if it is for a totally different chip), please use it. Most chips work fine with probe_jedec() even if the command sequence seems to differ at first glance. See also [[Random notes#Command_set_secrets|Command set secrets]]. | ||
The patch reviews may sound harsh, but please don't get discouraged. We try to merge simple patches after one or two iterations and complicated ones after a maximum of three iterations. | The '''patch reviews''' may sound harsh, but please don't get discouraged. We try to merge simple patches after one or two iterations and complicated ones after a maximum of three iterations. | ||
If you introduce new features (not flash chips, but stuff like partial programming, support for new external programmers, voltage handling, etc) please discuss your plans on the list first. | If you introduce new features (not flash chips, but stuff like partial programming, support for new external programmers, voltage handling, etc) please '''discuss your plans''' on the [[Mailinglist|mailing list]] first. That way, we can avoid duplicated work and know about how flashrom internals need to be adjusted and you avoid frustration if there is some disagreement about the design. | ||
That way, we can avoid duplicated work and know about how flashrom internals need to be adjusted and you avoid frustration if there is some disagreement about the design. | |||
Revision as of 17:46, 3 December 2023
Patch submission
The following guidelines are for coreboot, but most of them apply to flashrom as well: coreboot development guidelines. The really important part is about the Signed-off-by procedure.
We try to reuse as much code as possible and create new files only if absolutely needed, so if you find a function somewhere in the tree which already does what you want (even if it is for a totally different chip), please use it. Most chips work fine with probe_jedec() even if the command sequence seems to differ at first glance. See also Command set secrets.
The patch reviews may sound harsh, but please don't get discouraged. We try to merge simple patches after one or two iterations and complicated ones after a maximum of three iterations.
If you introduce new features (not flash chips, but stuff like partial programming, support for new external programmers, voltage handling, etc) please discuss your plans on the mailing list first. That way, we can avoid duplicated work and know about how flashrom internals need to be adjusted and you avoid frustration if there is some disagreement about the design.