On Tue, 2007-12-04 at 14:10 +1100, David Gibson wrote: > We've been back and forth on this several times, Paul and I finally > concluded this was the better option.
As long as I can just ignore it and use the separately-shipped dtc, I suppose it doesn't have to bother me too much. > It means we can feel free to use dtc for whatever new platforms we > wish to without people whinging about having to install a new tool. I think we're overestimating this 'problem'; really. But anyway, if we have to go ahead with it, can we make sure we keep in sync with the 'real' dtc? One way of doing that is as follows... It's not hard to make a git repository which is a simple 'transform' of another tree -- I have a couple, at http://git.infradead.org/?p=users/dwmw2/jffs2-ecos-core.git and http://git.kernel.org/?p=linux/kernel/git/dwmw2/kernel-headers.git The scripts to generate those are at http://david.woodhou.se/extract-jffs2-git.sh http://david.woodhou.se/extract-khdrs-git.sh http://david.woodhou.se/extract-khdrs-stage2.sh (The kernel headers one is in two stages because it has to mangle the files through unifdef too). I'm sure there are better ways of doing it, but the scripts I have work, and should hopefully serve as a vaguely useful example. I'd recommend making such a 'transform' which tracks the upstream dtc tree but with the files you want moved into the correct places. Then all we have to do to update the kernel's copy is pull from that transformed tree. Of course, it's possible that git has matured to the point where it can handle the 'renames' and you can just pull from the upstream dtc repository directly. I don't think that's the case though. -- dwmw2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
