On Fri, May 18, 2007 at 06:33:42PM +0700, Darmawan Salihun wrote:
Because this version of flashrom will be quite different in terms of code due to inherent differences between Linux/other Unix and Windows, I think it's better to put it as a "branch" of the flashrom directory.
Please don't make a subdirectory of flashrom. I would instead suggest creating a new directory in util/ e.g. named winflashrom or whatever you prefer.
I'm still thinking about the way to incorporate the flash chip and motherboard support in as seamless way as possible so that every newer chip/motherboard support will be merged easily.
I can come up with two ways:
1. Use a database separate from the programs (as suggest by Stefan) 2. Create a library used by both programs.
I prefer 2 a lot;
* No database file to keep track of, the binary ALWAYS works * For winflashrom the database needs to be sent to the kernel driver somehow, if not right now then I think at least in the future. That means extra work, when it could just be in code already.
The benefit of 1 is that the database can be updated at any time. But I think at least the Windows version should have more intelligence in the kernel driver than in the application so upgrading will be a largeish operation anyway.
In the mean time I need the information on how to commit the code once I have a tested version of the Winflashrom.
What you do is send a signed off patch to the mailing list. Use svn diff to produce it. Then people on the list review and if it looks good it gets committed. :)
Anyway, I wonder how the qa (Quality Assurance / auto build, etc.) system will handle a windows version source code :-? especially the header files.
What is your current development environment? I would like it a lot if you could write the software so that it is possible to build with MinGW, then it could be cross-compiled easily and binaries could be generated automatically.
//Peter