On 9/23/07, Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com wrote:
Hi,
Two points : 1) If you're ok, I can work on kconfig itself. 2) About the re-organization I'd like to create a tree like following arch/arm/ arch/arm/board <- the boards arch/arm/boot <- where will be store the u-boot & u-boot.bin arch/arm/config <- defconfig arch/arm/commom <- arch specific common arch/arm/lib <- the lib_arm arch/i386/ arch/i386/board arch/i386/boot <- where will be store the u-boot & u-boot.bin arch/i386/config <- defconfig arch/i386/commom <- arch specific common arch/i386/lib <- the lib_i386 common lib <- lib_generic drivers
If you want to take on reorganization of the source tree, cool. However, keep the following things in mind: - Maintaining stability is of utmost concern. Bite off small chunks at a time and post patches that do small, well defined things. - Make sure that patches which move files don't make changes to those files at the same time; it makes it easier to review the changes. - Reorganization of the source tree is unrelated to the migration to Kconfig. You won't need to worry about the Kconfig layout while moving files around. - One word: 'MAKEALL' :-)
It's probably best to start with the changes to drivers/ that you mentioned in your earlier email. It will be the least contentious of the changes. Changing the cpu/ and board/ layouts will require considerably more consensus.
As for Kconfig, I would like to handle the task of generating the initial set of Kconfig data files (which is a separate task from importing the Kconfig source files). I've got a plan in mind for migrating to Kconfig without breaking existing board ports.
Cheers, g.