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 -- Developer quote of the year: "We are juggling too many chainsaws and flaming arrows and tigers." -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
