[U-Boot-Users] [RFC] u-boot migration to kconfig

[Grant Likely <grant.likely@secretlab.ca>]

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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195