The authoritative svn master tree at flashrom.org and the Google ChromiumOS flashrom tree have diverged quite a bit in terms of hardware support, especially for Embedded Controllers (EC). That is unfortunate because all interface rework and all cleanups in main flashrom have to be ported by hand (if they are done at all) to the ChromiumOS tree with some potential for errors during merge/porting.
The EC support code in the ChromiumOS tree needs a few cleanups to be closer to the style and durability requirements we have for flashrom.org svn, but keeping the code outside our tree won't improve it. The same argument applies to Nvidia Tegra support.
The Linux kernel has a staging directory, I propose we use a similar mechanism for flashrom (without the special staging/ directory, though): Merge driver files as-is and clean them up in our tree, but have all hooks for the staging code inside #ifdef EXPERIMENTAL or somesuch. Any cleanups for that code can happen in flashrom.org svn, and whenever Google wants to merge the cleanups into their tree, they can do so easily. If code is determined to be ready for inclusion, we can simply remove #ifdef EXPERIMENTAL from its hooks.
Comments? Thoughts?
Regards, Carl-Daniel
On Tue, Jan 3, 2012 at 11:59 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
The authoritative svn master tree at flashrom.org and the Google ChromiumOS flashrom tree have diverged quite a bit in terms of hardware support, especially for Embedded Controllers (EC). That is unfortunate because all interface rework and all cleanups in main flashrom have to be ported by hand (if they are done at all) to the ChromiumOS tree with some potential for errors during merge/porting.
The EC support code in the ChromiumOS tree needs a few cleanups to be closer to the style and durability requirements we have for flashrom.org svn, but keeping the code outside our tree won't improve it. The same argument applies to Nvidia Tegra support.
The Linux kernel has a staging directory, I propose we use a similar mechanism for flashrom (without the special staging/ directory, though): Merge driver files as-is and clean them up in our tree, but have all hooks for the staging code inside #ifdef EXPERIMENTAL or somesuch. Any cleanups for that code can happen in flashrom.org svn, and whenever Google wants to merge the cleanups into their tree, they can do so easily. If code is determined to be ready for inclusion, we can simply remove #ifdef EXPERIMENTAL from its hooks.
Sounds good to me! This seems like a much better approach to help the code developed for Chrome/Chromium OS keep pace with upstream, and help us test upstream code and get it merged more frequently.
Note that in addition to the EC code itself, we'll also need to add the command-line processing to switch between SPI/LPC targets on the fly. This is the "-p internal:bus=" stuff we currently have in the chromium os branch.
On Tue, 03 Jan 2012 20:59:56 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
The authoritative svn master tree at flashrom.org and the Google ChromiumOS flashrom tree have diverged quite a bit in terms of hardware support, especially for Embedded Controllers (EC). That is unfortunate because all interface rework and all cleanups in main flashrom have to be ported by hand (if they are done at all) to the ChromiumOS tree with some potential for errors during merge/porting.
The EC support code in the ChromiumOS tree needs a few cleanups to be closer to the style and durability requirements we have for flashrom.org svn, but keeping the code outside our tree won't improve it. The same argument applies to Nvidia Tegra support.
The Linux kernel has a staging directory, I propose we use a similar mechanism for flashrom (without the special staging/ directory, though): Merge driver files as-is and clean them up in our tree, but have all hooks for the staging code inside #ifdef EXPERIMENTAL or somesuch. Any cleanups for that code can happen in flashrom.org svn, and whenever Google wants to merge the cleanups into their tree, they can do so easily. If code is determined to be ready for inclusion, we can simply remove #ifdef EXPERIMENTAL from its hooks.
Comments? Thoughts?
Regards, Carl-Daniel
*stand-alone* drivers could also be just disabled in the makefile by default. either way those are not a problem and i support your plan. i am not sure if other code that is more tightly integrated into other files as well can be dealt with appropriately with an #ifdef or if that would clutter the files too much. OTOH this might not be necessary... i guess we can discuss this in a review prior to inclusion... you dont plan to just drop them in i hope? :)
Am 03.01.2012 23:44 schrieb Stefan Tauner:
On Tue, 03 Jan 2012 20:59:56 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
The Linux kernel has a staging directory, I propose we use a similar mechanism for flashrom (without the special staging/ directory, though): Merge driver files as-is and clean them up in our tree, but have all hooks for the staging code inside #ifdef EXPERIMENTAL or somesuch.
*stand-alone* drivers could also be just disabled in the makefile by default. either way those are not a problem and i support your plan. i am not sure if other code that is more tightly integrated into other files as well can be dealt with appropriately with an #ifdef or if that would clutter the files too much. OTOH this might not be necessary... i guess we can discuss this in a review prior to inclusion... you dont plan to just drop them in i hope? :)
I hope David Hendricks will submit one patch for each hardware driver, and then we can review each of them to get them into a semi-mergeable shape and continue from there. Compilation will be disabled by default (full drivers with makefile hacks, hooks in other files with # ifdef) until the code is ready for prime time.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
David Hendricks -
Stefan Tauner