Dear Andy,
In message F9C551623D2CBB4C9488801D14F864C614E679@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.
- 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.
- 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