Dear Andy, In message <f9c551623d2cbb4c9488801d14f864c614e...@ex-mb1.corp.adtran.com> you wrote: > > > - How often a patches committed to the public repository > > - What is the patch review procedure - Has it changed recently? Why? > > do _you_ think it is a good procedure? > > - How many people are actively contributing - Is there are large enough > > core contribution team that you believe can support you going forward > > - What level of support can you expect from the community both now and in > > the future > > - Are there any clear policies (either explicit or implicit). For exampl> > > e, > > U-Boot has a policy of not introducing board-breaking changes unless > > there is a really good reason. Also, U-Boot questions patches that > > cause code/data size increases for arches/boards which do not benifit > > from a particular new feature > > Looking at the two choices side by side, these appear to be equal. This
Actually this is an area where you can collect objective, unbiased information from a number of data sources. Each of them alone is probably subject to error or misinterpretation, but together they give a pretty clear picture. 1) Commit statistics; these are trivial to get from the respective git repositories using the "git-dm" tool by Jonathan Corbet (see http://repo.or.cz/w/git-dm.git). Here one should pay attention that up to and including U-Boot v1.2.0 (commit f4eb545, dated Sun Jan 7 00:13:11 2007) both trees share a common history, so let's look at this separately: Common history: commits 0b666f8..f4eb545 2154 csets from 38 developers 8 employers found A total of 1919992 lines added, 279294 removed (delta 1640698) U-Boot history since: commits f4eb545..f5cdc11 (=v2012.04-rc2) 12648 csets from 647 developers 54 employers found A total of 1632473 lines added, 1132225 removed (delta 500248) BareBox history since: commits f4eb545..6a0ab1d (2012-04-14) 4346 csets from 72 developers 6 employers found A total of 458345 lines added, 1404718 removed (delta -946373) It has to be pointed out that the inital phase of Barebox is probably a bit untypic as it consisted mainly of large removals of major parts of U-Boot code, so let's also have a look at a somewhat shorter period - we skip the period where BareBox was using SVN and start with the first git commit (bc1e507, 2007-07-05 21:23:42). For U-Boot we chose a close date: commit f1152f8 (2007-07-06 02:50:19) U-Boot history since: commits f1152f8..f5cdc11 12212 csets from 630 developers 52 employers found A total of 1531006 lines added, 1099069 removed (delta 431937) Barebox history since: commits bc1e507..6a0ab1d 3657 csets from 72 developers 6 employers found A total of 377290 lines added, 865712 removed (delta -488422) So in the last ~5 years (since 2007-07-05 = 1748 days) we get these numbers: U-Boot BareBox ratio Commits 12212 3657 3.3 Developers 630 72 8.8 Employers 52 6 8.7 add per day 876 216 4.1 rm per day 629 495 1.3 chg per day +247 -279 As you can see, U-Boot has a significantly bigger community (both in terms of developers and contributing companies). Development is faster, too. 2) Project statistics at ohloh.net: compare http://www.ohloh.net/p/u-boot versus http://www.ohloh.net/p/barebox Note: this comparison is in favour of the BareBox project, as it includes all the common history up to and including commit f4eb545 (U-Boot release v1.2.0). 3) Mailing list statistics: compare http://lists.denx.de/pipermail/u-boot/ versus http://lists.infradead.org/pipermail/barebox/ For the period of October 2009 (when the BareBox mailing list was started) until today we see: U-Boot: total 57.3 MiB gzipped text = 1893 KiB/month Barebox: total 7.08 MiB gzipped text = 234 KiB/month Also, compare http://dir.gmane.org/gmane.comp.boot-loaders.u-boot versus http://dir.gmane.org/gmane.comp.boot-loaders.barebox For U-Boot see also: http://gmane.org/details.php?group=gmane.comp.boot-loaders.u-boot [http://gmane.org/details.php?group=gmane.comp.boot-loaders.barebox does not give much information.] > is one of those areas, however, that no one can be 100% sure about for > the next 5-10 years. Barebox may overtake U-Boot just like U-Boot did > for RedBoot. Or some other bootloader may take the center stage. This > is an unknown risk that has to be owned by the company that chooses to > adopt any third party code. This is true. Prediction is always difficult. On the other hand, U-Boot is a de-facto standard in the embedded industry; we currently support 990 board configurations in mainline (not counting the many, many out-of-tree vendor ports). This indicates a pretty high momentum for the project - it is unlikly that it would go out of scope any time soon - especially if you also take into account that the speed of development is still increasing. Compare the 990+ board configurations in U-Boot to 72 configurations in BareBox. > > > 2) I have a feeling we will always be porting everyone's bsp (that > > > already has a working u-boot) to barebox. > > > > > Which should not be _that_ hard considering that barebox is based on > > U-Boot, but I think the code has diverged quite a lot > > Which is what I said below. If it wasn't clear, these three "questions" > were presented to me in opposition of my choice to investigate more > Barebox as our universal bootloader. And yes, you are correct, the code > appears to have changed drastically. According to the Barebox list, > there would be a port required from U-Boot to Barebox for all drivers > that are needed from U-Boot as the driver model is more closely aligned > to the Linux kernel, though I never was answered whether drivers from > the Linux kernel would be easier to port. Neither way is easy, but usually it is probably easier to adapot U-Boot driver code to BareBox, than to port Linux driver code to either environment. > > > 3) I also don't really see the real advantage over standard u-boot > > > (what's the 'killer' application?). > > > > > I like the idea of barebox's posix file system API and environment > > handling. But I think that comes at a cost of size and speed > > The ability to have real mounted file systems in the bootloader, as well > as the posix like environment that Barebox uses are the two biggest Agreed - the file model and the driver interface are two areas where BareBox has a much cleaner design. Well, the driver model is something where U-Boot will soon draw level. > reasons for my wanting Adtran to use Barebox. This seems to me to be > less cumbersome than the way that U-Boot requires scripts to be written > inside of variables. Whereas I am use to this type of scripting (being You do not _have_ to do it this way. You can also run plain shell scripts. And there are other methods, like importing the envrionment from files on external media and file systems. > > > As for 1 & 2, these I just don't know about. I'm guessing that anything > > > supported in either the Linux kernel or already in u-boot should be > > > fairly easy to port into Barebox. Here, however, I have to define for > > > Mgt clearly what does "fairly" mean. I think this is definitely not true. There are many things are are _not_ easy to port to a boot loader - no matter wether it's U-Boot or anything else. An OS is a significantly different beast. Just to name a few things that make a lot sense in an OS but are not easy to add to a boot loader: - complete TCP/IP stack (especially if you also want it to be robust and reliable, and eventually even IPv6 aware) - concepts like processes, users, name spaces, ... - encryption and key management (which implies user management) - full RAID support > Right. This is what we have done already. The requirements list for > the universal boot loader is not that vast. There are truly only a few > requirements: Must be able to load a fail-safe application that would > rebuild itself remotely, must be able to boot either our IP Binary > image or a Linux kernel, must be able to read/write both NAND and NOR > flash devices, and must support a wide range of platforms. > > As you see, the requirements fit both Barebox and U-Boot at the moment. > My requirement of being easy to use, is not a requirement the company > has enforced on us. These requirements are probably fulfilled by both U-Boot and BareBox, and depending on your personal preferences you may prefer one or the other here or there. Regarding the "wide range of platforms" the board count is 990 : 72 for U-Boot (in mainline; note that barebox has 65 in ARM, and only one each in blackfin, nios2, openrisc, ppc, and x86; and two for mips) - it is pretty much clear that BareBox is almost exclusively ARM-centric. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Is a computer language with goto's totally Wirth-less? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
