From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Date: Thu, 16 Dec 2010 18:23:30 -0600 Subject: [U-Boot] [x-loader] Re: [ANNOUNCE] Public x-loader git tree In-Reply-To: <20101216203859.1974BD1CABC@gemini.denx.de> References: <20101216203859.1974BD1CABC@gemini.denx.de> Message-ID: <4D0AAD82.604@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk had written, on 12/16/2010 02:38 PM, the following: > Dear Anand, > > In message you wrote: >> To this end, we have set up an x-loader git tree on gitorious, and >> seeded it with Steve Sakoman's x-loader tree [1] as of 15 December >> 2010. (Thanks Steve for unifying so much of the forked code, and >> getting rid of the dependency on u-boot, and more!). > ... >> Deva and I have volunteered to maintain the x-loader code - everyone >> is welcome to contribute and help make it better. >> (This is our first attempt at maintaining a software project - so any >> help is appreciated). > > May I ask what your goal is for such a project? > > You mentioned that x-loader was derived from U-Boot, and shares some > code. What is the benefit from maintaining it as a separate project? > > You write "getting rid of the dependency on u-boot", and try to make > this sound as an advantage. Is this really the case? Or did you just > cut off your feed from upstream? The statement was more in-terms of some ghastly ln -s ../../../u-boot/include/asm/mux.h kind of stuff which existed in x-loader previously, practically making build of x-loader requiring that u-boot source be in the same location as the x-loader. yeah, it was atrocious, and is one of the steps of breaking that dependency that took place. > > Would it not make more sense to merge it into the U-Boot tree, so it > gets maintained as one project, and code is automatically kept in > sync? My 2 cents: The eventual long term goal is to make u-boot/other alternatives (such as OMAP configuration header[1][2]) capable of replacing x-loader. We have much to do to reach that stage(while we work on it in parallel). in the meanwhile, current xfurcation (since there are more than 5 or 6 different known forks at least) make it impossible to do where we stand and what needs to be done. In a way, considering a single x-loader as a standin solution while a final alternative evolves and becomes practical is important and is an evolutionary step IMHO. Ref: [1] https://gforge.ti.com/gf/download/docmanfileversion/229/3870/linux-without-a-bootloader.ppt [2] http://nishanthmenon.blogspot.com/2009/05/configuration-header-no-more-x-loader.html -- Regards, Nishanth Menon