On Sun, 18 Apr 2021 21:43:06 +0200 Xabier Oneca -- xOneca <[email protected]> wrote:
> Hi Bernhard, > > > The usual way to update out kconfig was to pull the upstream version > > from the kernel, refresh our patch (if we had one) and commit > > both. We usually picked the current stable kernel version and mentioned > > that version in the commit message for future reference and updates. > > > > Usually we upstreamed eventual fixes or improvement to Sam resp. the > > kernel kconfig which were not busybox specific as to minimize local > > patches. > > > > I think such a refresh is overdue. Hence if anybody is willing to > > carefully refresh, that'd be awesome. I assume this would automagically > > pull in nconfig support, too. > > I tried, but I couldn't find a clear commit upstream that was the > similar to "build system overhaul" > (https://git.busybox.net/busybox/commit/?id=7d219aab70e6951ab82c27c202cac05016696723), > or any following it. Yea, it's a pity that Denys did not mention the exact version he based off. Bites later on ;) I'd start with a stable kernel tree from around that commit. What i do remember is that when i did f3d1e213fef45ba2df4090e9cd02217d1ef82f00 there were rather few diffs to upstream apart from out Busybox specific hunks, in case that helps. That'd suggest that Denys may have based off something < 2.6.26ish, maybe 2.6.13 > > Busybox's kconfig has a lot of custom modifications and has diverged > wrt upstream. We have some (crucial to busybox) but not _that_ many i think. See git log -p -- scripts/kconfig/ or browse through gitk --all scripts/kconfig/ git diff 7d219aab70e6951ab82c27c202cac05016696723..HEAD -- scripts/kconfig/ as you certainly know. Unfortunately i do not see the initial patch with busybox specific stuff but maybe there was none or only those that are maked with /* bbox */ in the huge overhaul commit :-/ That's the exact reason why it's nice to carry an ontop patch and update instructions along the actual bump. But anyway, it's fixable either way. > I like the idea of syncing both kconfigs. If it is desirable, I can > try porting the latest version. But I advance there will be a lot of > changes... > But I was thinking also porting some other changes and making both > trees alike... I'd start with factoring out a the busybox specific hunks, storing that away in a separate patch in scripts/kconfig-busybox.patch like we do (or have done, rather) in the other projects we're interrested in. Not sure if buildroot is in the boat of reliable and friendly maintenance of infrastructure bits TBH. And/Or pull upstream kernel's kconfig and going through the diff, sorting busybox stuff from general improvements/fixes. Crucual part is to make sure that the config, include/ generated headers remain about the same WRT pristine busybox master. Special care has to be taken to keep stuff like 'allnoconfig' identical or plausible, again diff config and include and other generated bits. If hunks like 627052e75d6657a029a328cffd0832cb581b82fd prove to be troublesome then drop cosmetics like that. I certainly won't complain :) Many, many TIA && cheers, _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
