Hi Masahiro, On 27/10/14 19:13, Masahiro YAMADA wrote:
Hi.I've been thinking how to move so many CONFIGs to Kconfig. First, I want to move many boolean macros such as CONFIG_CMD_*, because it seems easier than string, int, hex configs. Roughly, we have two options, I think. [1] I do this work for all the boards I will prepare many entries in Kconfigs and also move lots of configs options by a tool. Pros: - Possible to move many options at one time Cons: - Cause lots of conflicts - It is pointless to touch lots of unmaintained boards that might be removed by the end of this year - Hard work for me [2] Each board maintainer takes care of boards he is responsible for. Procedure: 1. I will create many entries in Kconfigs without dependencies ("depends on" and "select") 2. Each board maintainer will move config options from his board headers to defconfigs (*) (I expect most of active boards will be switched at this step.) 3. Many of unmaintained boards ( = not converted to generic board) will be removed by the end of this year. 4. I will forcibly convert left-over boards. These boards are almost inactive, so this conversion will not produce much conflicts. 5. Implement "depends on" and "select" correctly (*) You can edit directly configs/foo_defconfig. Or you can use Kconfig functions in case you may introduce a typo. Run "make foo_defconfig" Run "make menuconfig" Enable config options you like Select "Save". Run "make savedefconfig" Run "mv defconfig configs/foo_defconfig" Remove unnecessay CONFIGs from your board header files Pros: - Reduce the possibility of significant conflicts - Avoid needless efforts for unmaintained boards Cons: - Patch for each board will fly around - Take longer time At first, I was planning to do [1] but it would disturb the development on SoC subsystems. I see SUNXI custodians are touching their Kconfigs and defconfigs very often. [1] would cause conflicts between u-boot/master and u-boot-sunxi/{master,next}. I also many boards are being dropped these days, which increase the conflicts. I am thinking [2] is better. Comments are welcome.
I recently tried to do [1] for a bunch of SPL #defines, and the attempt ended in me git stashing the whole thing and putting it off for a later date. The amount of work this approach requires feels very prohibitive, and I agree that it is likely to be disruptive, so I'm in favour of [2] as well. -- Regards, Nikita Kiryanov _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
