On 18.01.2010 00:57, ron minnich wrote:
I think for chip support forking the support software may look bad from a "software engineering" point of view, but is at times the only practical option because (to be as polite as possible) the implementation of many of these chips is not that great.
While this may be true for coreboot, this method caused huge pains in flashrom because people didn't even read the code before they copied/modified it. The worst cases were 100% copy-paste jobs where only a search/replace of the function names had been done. Over time, some of the copied files got modified and others stayed the same. A sizable chunk of old drivers contradict the datasheets because people forgot to actually adapt the driver to the chip after copying. Fortunately, a detailed analysis of code vs. datasheets allowed us to overcome the duplication and now ~80% of the old chip drivers can be killed thanks to the improved infrastructure.
I do recognize that coreboot support for a chipset is way harder to write and check than flashrom support for flash chips and agree that "looks safe" changes to unified multi-chipset code in coreboot can be a huge source of bugs.
What strikes me as odd is the fact that many chipset files in the coreboot source tree just got a search/replace treatment from another chipset, even if some feature is not even present on the new chipset. Would a dedicated "template" chipset directory help people implementing support for completely new chipsets?
Regards, Carl-Daniel