[U-Boot] Mini Summit 2014 Followup / Transcript of Open Discussion

Detlev Zundel dzu at denx.de
Fri Oct 17 17:02:28 CEST 2014


Hi,

it was a pleasure for me to meet so many of you this Monday in
Düsseldorf at the ELCE.  As many as 17 current custodians and 2
prospective new custodians were present at the event:

  Hans de Goede - Sunxi
  Alexey Brodkin - ARC
  Marek Vasut - USB
  Scott Wood - NAND
  Joe Hershberger - Networking
  Anatolij Gustschin - Video
  Heiko Schocher - I2C
  Stefano Babic - ARM i.MX
  Stefan Roese - PowerPC 4xx, CFI flash
  Wolfgang Denk - PowerPC 8xx, 82xx, 85xx, 5xxx, 7xx, 74xx
  Lukasz Majewski - DFU, OneNAND
  Tom Rini - Master of the git tree
  Pantelis Antoniou - MMC
  Daniel Schwierzek - MIPS
  Masahiro Yamada - Uniphier, Kconfig / Kbuild
  Simon Glass - x86, Driver model, patman, buildman
  Nobuhiro Iwamatsu - SH architecture
  Vince Bridgers - SoCFPGA (soon)
  Przemyslaw Marczak - PMIC (soon)

The six talks gave rise to a lot of good discussions and the
presentation slides are now up on the wiki page[1].

The page is topped with a picture of the participants of the discussion
round in the evening.  I started adding the names of the people that
gave me explicit approval to do so but I would like to extend this list
somewhat further.  Whenever there is an NA without a question mark, then
I know the name and will fill it in when I get the approval.  If there
is a question mark behind it then I'm unsure and would be glad to get
some help _in addition_ to the approval ;)

As promised, here are my notes that I took during the evening
discussion - feel free to follow-up on individual items by cutting out
the rest of the mail:

--------8<-----------------8<---------

* Open Discussion

** ARM core vs ARM SoC custodianship

Collection of patches should go to mainline in one bunch, rather than
splitting them for every custodian repository.  Individual custodians
can ack parts of such a series.  This should be the default - custodians
should only pick up individual bits when those bits are pretty isolated.

** Getting new Custodians

Przemislav wants to apply as custodian for a PMIC tree.  This should
be handled by sending a patch to the ML in which he adds himself as a
custodian.  Once this is acked by Tom, the git repo can be set up.

** Testing

Problem is twofold:

- Hardware

Lots of hardware is available in a distributed fashion at individual
places.  A central lab will not happen, so one should maybe start
collecting information on people volunteering to run testcases, say for
every release candidate. (TESTERS?)

Boards should only be removed when they break during builds.  There is
no policy for automatic board removals.  The idea of a "board watchdog"
that times out after a certain amount of releases and has to be reset by
a successful test was not greeted by enthusiasm.  Most people believe
this will not work.

Side-note: An interesting hardware project from the Novena guys can
actually simulate an sd-card. With that setup one can feed test images
easily to systems under test.

- Software provisioning

There are lots of test frameworks available but none of them seems to
have no problem.

Tests in U-Boot can be successfully done in sandbox.  Sandbox is a
powerful test harness.  Simon has a setup in which sandbox boots the
U-Boot part of Chrome-OS including secure booting and a display.

Booting an U-Boot for tests from within U-Boot is still not supported
and will not be.

** printf vs puts

Maybe the puts usages will be phased out when moving to debug macros of
whatever kind.  Such macros are wanted by everybody but a concensus on
what they should look like was not reached.

No further feedback that "printf" without a format string needs to be
converted into puts shall be given on the mailing list.

** switch malloc to malloc_or_die, as glib does

Motivation: The error paths of failing malloc calls are usually
completely untested, full of bugs and they bloat the binary.

We have an "xmalloc" (sometimes known as malloc_dnf (do not fail)) in
cli_hush that has the semantics of printing an error message and going
into an infite loop on unsuccessful allocations.

The suggestion was to move all malloc calls to this semantics.  It
became pretty clear after a short discussion that there are situations
in U-Boot where failing mallocs _need_ to be handled.  So generally
switching to this behaviour is not an option.

Adding an "opt-in" malloc outside of cli_hush with this behaviour was
not greeted with much enthusiasm.  A patch to the ML introducing such
a malloc_dnf and switching users to it can then be discussed better.


** SoCFPGA patches

The fact that a large set of patches for the SoCFPGAs was merged after
-rc1 was questioned as it does not 100% comply with the rules.  The
patches constrained to SoCFPGA were no (big) problem, but one of those
patches broke mkimage and as such had an impact on the whole project.

The lesson should be - custodians should send out pull requests soon
after the merge window opens up.  Big chunks should not be pulled in
after -rc1.

The -next branch should be declared rebaseable and be used more.
Once -rc1 is released, things can then be pulled into the next
branch.  Only bug fixes should go into the later -rc's.

** Custodian expectations

It seems Albert doesn't like to pull from topic branches, so maybe
simply do not offer topic branches for him to pull.


--------8<-----------------8<---------

PS: There were a few people taking pictures at the event and I'm
certainly interested to see them.  So if possible, send them over to me
personally.

Thanks to everyone!
  Detlev

[1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014

-- 
Emacs seems a more likely candidate  to contain a mail system than the
mail system to contain an Emacs, so this is the way it was done.
                                            -- Bernard S. Greenberg
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de


More information about the U-Boot mailing list