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
Best Regards
Le 23/09/07 0:32, « Grant Likely » grant.likely@secretlab.ca a écrit :
On 9/22/07, Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com wrote:
Hi,
That's why I've propose my help in my first e-mail if it's possible. And I agree with you about to do one step after an other. Even if I've nearly finished to migrate the drivers to a neworganization, I'm waiting until the Kconfig changes are in the tree.
Best regards.
Sorry, I misread your original question. Yes, of course you can help with the migration! :-) As I mentioned, I'm doing a first step of modifying the build system to enable conditional compilation. I'll have those patches submitted to the ML in the next few days.
Both the common and drivers directories can be organized. I recommend waiting for the build patches to be merged into the -testing tree and basing your changes on top of that. Then you can post your changes to the ML. Hint: don't try to move all the files in a single patch. Split the move up into smaller chunks.
Another task that needs to be done is to import the Kconfig source code into u-boot and build it. I haven't figured out when I'll be able to take on that task yet. This work can be done in parallel with the build system changes. It's not until we start actually *using* kconfig that the changes will require coordination.
Cheers, g.